Re: mbarcode
 

No, there seems to be some problem with the way hildonmime works atm.

In the GTK+ version of mBarcode I called abook functions directly to add the vCard, but getting the abook header to work in a C++ program was throwing up errors.

I therefore decided to write the vCard to a vcf file and open it using the mime handlers (which works in the filemanager for example), however, if I try to call uri_open directly it just does nothing, and if I use the QDesktopServices::openURL() function then it just opens the vCard in the browser as text (even though the implementation and docs look as though it should open the file with the correct handler app).

Any help/ideas gratefully accepted.

P.S. As long as mbarcode is left open, the .vcf file will be left in ~/.mbarcode/temp/

Re: mbarcode
 

HI Josh

No not particulary scanning books, but I was trying out the app and there were some books to hand which I tried, which were successful

Its either one of 2 things that I can think of, 1 is because I am in the UK and choosing poor products to test on, or 2 im selecting the wrong urls for checking

Re: mbarcode
 

Morning chaps.

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...

Fingers crossed those work and I've not broken something else while fiddling! ;)

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.

Re: mbarcode
 

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 ;)

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.

I think we should place it in ~/.config/mbarcode/temp/ since that is where the other config files are stored.

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.

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.

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).

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?

Re: mbarcode
 

Seems like I was wrong! :D I think the Qt Mobility packages are available in v1.0 from the Nokia Repos after all :D Meaning that you don't need to have Extras-devel enabled to use these.

I suggest we try to move to the Qt Mobility Contacts API for the vCards then.

This also means that we have a lot easier access to GPS positioning and Messaging services, giving us a few more nice features to play with :)

Re: mbarcode
 

My thinking was that if it's really a "plugin", it shouldn't be accessing anything from the class (yes, it needs to connect to the barcodeDecoded function, but that doesn't need to pointer; that's the magic of Qt's slots/signals.)

At least, none of the current plugins require anything from the MainWindow class...

Re: mbarcode
 

You're right about that there are no plugins using anything but the signal as of now, I just thought it could be useful for some plugins to have access to more data from there. I might be wrong, though ;)

How would you go about and do the connection without passing down a MainWindow class pointer? Is it enough with the QWidget* to do that?

Re: mbarcode
 

Yeah, just a QWidget* is enough. I did a quick test earlier, and that worked fine.

Re: mbarcode
 

Ok, cool. I guess the only pro of having the whole class passed down I can think of then is that you get full auto-complete with Qt Creator that way.

However, I don't see the great benefit of switching to QWidget* other than having one class less to depend on (i.e. one less #include), or am I missing something?

To me it seems to be only a question of how one likes to structure the relationships between the plugins and the main app.

Re: mbarcode
 

thanks, vcard works now!