Notices

Ubuntu (on which Maemo was based, right?) is popular, and has run on more powerful machines...

I'm not saying that the ability to run trojans on *nix based systems is impossible (in fact, I did find two known occurances). I just highly doubt that the main reason for a lack of trojans on Linux is popularity.

Besides that, Android is farm more ubiquitous than Maemo, yet they, running similar programs (installing from barcodes) have yet to be threatened by trojans.

[edit]
An interesting argument would be that android is itself a trojan, lol (google, big brother, yada yada)

OK, I thought about trojans too. But at least we trust lardman, don't we? One little digital sign (I mean PGP or something like that) will solve the problem.

Well it's certainly an interesting idea, and would be interesting to implement so yes, why not (though with big warnings if you enable it, etc., to avoid any possible problems with Trojans and the like).

I think that encoding an URL to a plugin would probably be the best method (to contain the code, the barcode would need to be pretty big), in which case any type of plugin could be specified, which brings us back to possibly just providing a link to an .install file somewhere (as I guess plugins will have separate packages).

Part of the goal of moving to Qt was to allow Python integration, so it will certainly be possible to try this out.

Ah, I see - thanks for clarifying. I will try asking on #zbar and the forum, thanks.

Hi lardman,

When I run mbarcode on the N900 and hit the scan button the video refresh rate is very slow compared to when using the camera. Is it clear why this is happening? I assume it's something to do with the processing of the barcode but other barcode scanner apps I have used have the same refresh rate as the phone's camera app so I am just curious to know what's happening there.

Thanks,
Paul.

Yes, this is somewhat intentional.

I dropped the video frame rate down as 30fps isn't really needed to perform barcode scanning. It should be possible to use full frame rate data (iirc) as my frame callback will just tell GStreamer to get rid of the frame if it's busy.

However, as the GStreamer pipeline is threaded, running processor intensive code such as the barcode decoders can cause the images drawn to the display to get backed up. This is especially bad when the libdmtx code is run (it runs in its own thread and is limited to being run only twice a second as it's so processor intensive).

I'm certainly happy to hear ideas for improving the performance and perhaps not using GStreamer at all would be one option here (not to mention replacing libdmtx with something that's faster and more efficient).

Right, I've been a bit quiet, mainly as I have lots of work on atm.

I have found the time to package up and push gst-dmtx and gst-zbar to extras-devel though (the gst-zbar currently in extras-devel will probably not work as it's missing a link to a dep, and the autobuilder was playing sillybuggers yesterday and rejected my fixed package, will try again in a little while).

So both gst-zbar and gst-dmtx can be added to a pipeline (I've been testing with the shortlived Python version of mbarcode), but I've yet to work out how to actually get messages from either element.

The other major issue is that gst-dmtx is shockingly slow, I've been testing with 3 queues, one for the xvimagesink, one for gst-zbar and one for gst-dmtx. If gst-dmtx is added to the pipeline and frame skipping is turned on it stalls the pipeline for ~20s before things start working (and even then I don't know if it's actually working as I'm not sure how to get to the messages).

So basically, my feeling is that this isn't going to improve things at all, so I'll probably just use the pipeline + decoder stuff I have been using up until now in the C version of mbarcode and crack on with the Qt port.

mbarcode is dead now?

No, I'm just extremely busy at work (where work is not hacking on the N900 unfortunately).

I just pushed 0.0.8 to extras-testing (from a month ago I know, but I do still get emails with people commenting about 0.0.7)

If anyone fancies hacking together a Qt ui that would be much appreciated, otherwise my workload should settle down in a week or so, so I'll get back to the Qt porting then.

Sorry for the delay!

I would like to ask for a new feature / changed behaviour. I would like to use the camera key on the N900 (or some other key available on all devices, or a screen button, I don't especially care) to "take a picture" of a barcode, especially one that needs to be decoded by the slow dtmx library.

I'm finding it very hard to hold the camera steady once I've got a good, in-focus picture of the barcode.

If I take a picture of the barcode, a message can pop up saying, "attempting to decode" and "no valid barcode found" or the barcode value can just be displayed.

The way things are currently, it is very unclear what's going on. I'm pointing at a barcode, it is in focus, but nothing's happening! My hand is getting cramped! The focus just slipped out again! Argh!