Active Topics
-
The N900 is now 15 years old! (9)
to Nokia N900 by Arno_11 - 17 hrs, 23 mins ago -
Sailfish OS for the Motorola Moto G7 Power (XT1955-5) - (ocean) (4)
to SailfishOS by Maemish - 6 days, 5 hrs ago - more...
|
2010-07-06
, 17:38
|
|
Posts: 376 |
Thanked: 56 times |
Joined on Jan 2010
|
#322
|
Originally Posted by joshn53
HI Josh
Sonic, are you scanning books specifically? If so, my ISBN plugin may be helpful; it looks up ISBN/EAN numbers on Amazon. It's successfully looked up every book I've tested so far.
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
|
|
2010-07-07
, 09:21
|
|
Posts: 2,102 |
Thanked: 1,309 times |
Joined on Sep 2006
|
#323
|
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.
Last edited by lardman; 2010-07-07 at 10:06.
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.
Last edited by lardman; 2010-07-07 at 10:06.
| The Following User Says Thank You to lardman For This Useful Post: | ||
|
|
2010-07-07
, 12:27
|
|
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
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.
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.
Originally Posted by lardman
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.
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!
Originally Posted by lardman
I think we should place it in ~/.config/mbarcode/temp/ since that is where the other config files are stored.
P.S. As long as mbarcode is left open, the .vcf file will be left in ~/.mbarcode/temp/
Originally Posted by joshn53
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(?).
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.
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
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.
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?
Originally Posted by lardman
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).
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...
Originally Posted by lardman
Isn't the 1D plugin deprecated? I believe it does nothing but to serve as an example plugin at the moment.
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.
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.
|
|
2010-07-07
, 12:58
|
|
Posts: 252 |
Thanked: 252 times |
Joined on Nov 2009
|
#325
|
Originally Posted by dragly
Seems like I was wrong!
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 the Qt Mobility packages are available in v1.0 from the Nokia Repos after all 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
Last edited by dragly; 2010-07-07 at 13:03.
|
|
2010-07-07
, 13:03
|
|
Posts: 111 |
Thanked: 80 times |
Joined on Oct 2009
|
#326
|
Originally Posted by dragly
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.)
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(?).
At least, none of the current plugins require anything from the MainWindow class...
|
|
2010-07-07
, 13:12
|
|
Posts: 252 |
Thanked: 252 times |
Joined on Nov 2009
|
#327
|
Originally Posted by joshn53
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
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...
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?
|
|
2010-07-07
, 13:28
|
|
Posts: 111 |
Thanked: 80 times |
Joined on Oct 2009
|
#328
|
Originally Posted by dragly
Yeah, just a QWidget* is enough. I did a quick test earlier, and that worked fine.
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?
|
|
2010-07-07
, 13:33
|
|
Posts: 252 |
Thanked: 252 times |
Joined on Nov 2009
|
#329
|
Originally Posted by joshn53
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.
Yeah, just a QWidget* is enough. I did a quick test earlier, and that worked fine.
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.
|
|
2010-07-07
, 14:24
|
|
Posts: 1,096 |
Thanked: 760 times |
Joined on Dec 2008
|
#330
|
thanks, vcard works now!
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:
Any help/ideas gratefully accepted.
P.S. As long as mbarcode is left open, the .vcf file will be left in ~/.mbarcode/temp/