Thread: mbarcode
View Single Post
Posts: 252 | Thanked: 252 times | Joined on Nov 2009
#324
Wow! There has been a lot of posts since I last checked this thread. I'll try to get in here with some comments on the different topics now

Originally Posted by lardman View Post
Does anyone know of any example code for manipulating the addressbook/contacts list using purely Qt? If so I'd prefer to move to that directly, otherwise I guess it's possible to pull in glib headers, I'll soon find out!
I believe our best choice for the future is the Qt Mobility Contacts API. The only problem is that the Qt Mobility library is still only in extras-devel, and thus cannot be moved up to extras testing. Our best choice for now is probably to either use your .vcf workaround or figuring out how to talk directly to the abook.

Originally Posted by lardman View Post
P.S. As long as mbarcode is left open, the .vcf file will be left in ~/.mbarcode/temp/
I think we should place it in ~/.config/mbarcode/temp/ since that is where the other config files are stored.

Originally Posted by joshn53 View Post
The plugins system is cool! To get the feel for it, I made a simple plugin to look up ISBN's on Amazon. Is this something Of General Interest?

Also, one code suggestion: it would seem cleaner to pass a QWidget* to initInterface, so each plugin doesn't need to know about mainwindow.h. I'd be happy to do this if you want to give me commit access.
Thanks! I think passing a QWidget* might be a solution, but you would have to cast it to a MainWindow (which is going to be renamed to something less general very soon) if you want to use the functions/data in the class. I don't really know which gives the most overhead, and I suggest that we continue to "know about" the main app unless it is causing any big problems(?).

And please share your plugin if you haven't done so already I've been looking at Amazon lookups myself, but I haven't got the time to make a plugin for it.

Originally Posted by lardman View Post
Yes, that does sound reasonable. The portrait support is just how the main page rotates, and in no way designed to be that way on purpose.

Before you start expending time on this though, there was talk of moving to a UI more like that of maemo-mapper - i.e. something pretty and full screen (camera in this case) with buttons as overlays, and then the history/till-roll list could be a pull-out tab (in which case it may be better left as a vertical list, I don't know). Any thoughts in general (from everyone) on whether a prettier UI would be beneficial?
This is my first priority on mbarcode now, alongside working on the PythonQt imlpementation (unless you guys want me to do something else). I'll try to make it mostly like you describe it, with overlay icons and pull-in menus. I'll just have to practice a little with QPainter first.

Originally Posted by lardman View Post
I've just pushed a new version of mBarcode + the plugins.

Now the plugins should depend on mBarcode, and the QRcode plugin should add vCards...
I think we should add a recommendation for the plugins as well (at least the "official" ones) and go for a enable/disable option in the settings. That is the reason why mbarcode depended on the plugins and not the other way around the begin with, but I think we can solve this with the "Recommended:" option in the control file. I'll check this out later (if noone beats me to it).

Originally Posted by lardman View Post
Edit: not all the plugins, the 1D plugin refuses to build and I've no clue why - missing a header which should be pulled in by one of the deps. I'll try to fix that this evening, but in any case not a big problem as there were no changes there other than to the control file.
Isn't the 1D plugin deprecated? I believe it does nothing but to serve as an example plugin at the moment.

And finally, a question from my side: When we'll do the renaming of MainWindow into MaemoBarcodeWindow (or something similar), should we at the same time rename "SinkPlugin" into "PluginAction"? I think SinkPlugin might be a bit hard to understand the use for, while all it really does is to add a button with an action applied to it to the list. Thereby the name PluginAction.

What do you guys think?

Last edited by dragly; 2010-07-07 at 13:03.