Re: mbarcode
 

The open/close fps bug might be caused by some faulty checking of the lens cover state. I'll have a look at it and see if I can reproduce it. If I do forget it, please file a bug in http://bugs.maemo.org so I get a reminder.

As to bundling the plugins into the main app, this might be a good idea. I thought the app manager would install the plugins automatically when they are named in the "Recommends" field in the package. If there is no way to make this work, I'll look into bundling it all together.

@wikiwide: just as a note if you don't want to copy the compiled file into /usr, you may place your .so in /home/user/.config/mbarcode/plugins instead. I don't know why it doesn't work without qmake, and sadly, Qt isn't saying too much about why plugins won't load. I would suggest you make it work with qmake first, and then try to compile it by hand. Good luck!

Re: mbarcode
 

It seems that -shared option of g++ just turns off all errors, ignores them. So I try to link without -shared option and look at errors.

EDIT: Now I use these commands.
g++ -c -pipe -O3 mb.cpp
g++ -Wl,-rpath-link,/usr/lib -L/usr/lib -lQtCore -lQtGui -lQtDBus -lpthread -lzbar -shared mb.o -o mb.so

It still says "Could not load"

When I remove -shared from the second line, it says "undefined reference to 'vtable for class'". If anybody knows how to resolve it, he is welcome (there are neither constructors nor destructors in the two classes).

Re: mbarcode
 

@Wikiwide: I believe it has something to do with putting all functions and headers into one .cpp file. I tried compiling your code with all classes and headers in one file and it failed to load. Separating them into their respective .cpp and .h files made the plugin compile and load without problems.

I did this with qmake and make, but I believe it should be possible to do this with g++ alone. The commands issued by qmake and make are as follows:
This of course includes some of Qt's moc stuff, which I'm not sure is needed for this example. I'm also unsure wether g++ will play along with all of Qt's macros without having qmake run together with make.

I don't think that plugins for mbarcode are the easiest thing for testing wether or not Qt will play ball without qmake and suggest that you test these things out with simpler Qt examples first.

In any case, good luck!

Re: mbarcode
 

I have a simple Qt example application. It does work perfectly without ./configure, without Makefile, without qmake.pro. It also has separate .cpp and .h files, and moc turns the header file into a cpp file, too.

The moc is needed anywhere Q_OBJECT macro is used. It's used for slots and signals. And slots and signals are necessary here.

I see...
Maybe, running moc on my one cpp file will generate the second cpp file, and then I can feed the two cpp files to g++.
Or I could separate my cpp file into one cpp and one h, then I would have three files to feed to g++.
The problem is, moc can only be run in MADDE on Windows now, while I would prefer to do as much as possible on N900 itself.
How could I possibly install moc on N900?

Quote from documentation:
If you get linkage errors in the final building phase of your program, saying that YourClass::className() is undefined or that YourClass lacks a vtable, you have not included that object file in the link command.

P.S. How can I click Thanks! ten times on your reply?

Re: mbarcode
 

Well moc and qmake can apparently be built on-device: http://talk.maemo.org/showthread.php?p=771651

I'm not sure if someone's pushed these to one of the extras-* repos yet or perhaps you could post in that thread and see if someone could distribute the binaries directly.

Re: mbarcode
 

@Wikiwide: I'm glad to hear that my post helped you :)

I've just tested installation of mbarcode now and it seems like the Recommends field in the deb package does nothing. In other words, all plugins, including the standard ones, have to be installed manually by the user - which is not very user friendly.

So the best solution is probably to bundle all the standard plugins into the main mbarcode package, like joshn53 suggested. I have done this now and just pushed an update version. Let's see if it works as expected :)

I've also set it to conflict with the old plugin packages, so that the user does not install them side-by-side with the bundled plugins.

Re: mbarcode
 

Seems like the update and bundling went fine, although users updating from previous versions have to uninstall the plugin packages first. Otherwise the application manager will complain about the packages being in conflict.

If noone objects the bundling I'll request that the old packages are removed. Plugins which are non-standard may still be installed as separate packages.

Re: mbarcode
 

I like it! Is there anything holding mbarcode back from being released to extras-testing?

Re: mbarcode
 

I think it could be pushed up to extras-testing now. Even if there are a fair amount of bugs left to resolve, there is nothing mission critical blocking it. It could be good to move it up and see if we can find some more bugs as well.

Re: mbarcode
 

Would it not be better to leave the plugin packages alone and change the mbarcode package to depend on each plugin?

In fact it might even be worth creating a meta package called mbarcode-plugins, and then we can add each plugin to that meta-package to avoid fiddling around with the mbarcode package directly and instead just make it depend on the meta-package.

I'm not sure how the circular dep of the plugins on mbarcode would be handled, but there must be a way to do this cleanly without needing to modify the mbarcode package each time a plugin needs an update.