[maemo-developers] mbarcode/maemo-barcode dialog oddity and progress report

[From: Simon Pickering]

On Thu, 2009-10-15 at 10:43 +0100, Graham Cobb wrote:
> On Thursday 15 October 2009 09:10:44 Simon Pickering wrote:
> > Replying to myself, another option (which is the same one that Android
> > Scan/CompareEverywhere uses) would be to move the "scraping" to a
> > server. This might let me use a single key for all the queries (though
> > it may still break the terms and conditions, I'd have to look) and would
> > also reduce on-device processing and the amount of data that needs to be
> > transferred.
> 
> While you are tolerating discussion of enhancements!...

lol :)

> If you do use a server, it would be great if you implemented an "offline" mode 
> where I could scan barcodes all day without network connectivity and, later, 
> process them when I am online.  Some of the places one might want to scan 
> barcodes (barcodes on display adverts, on buildings like in Westergasfabriek, 
> or in warehouses) might not have great network connectivity.  Most 
> professional barcode readers which I know of seem to do the scanning offline 
> and process the barcodes once they are plugged into their docking/charging 
> station.

Yes, in any case I was planning on allowing the raw data to be saved if
a lookup is not possible (for e.g. isbns and also for web urls, etc.), I
currently assume an internet connection (which should apparently be fine
for Fremantle ;)), but I need to get the code to ask for one and/or have
an offline scanning setting (oh dear more gui elements - a menu!)

> This brings up a slightly larger question of how modular is your current 
> implementation?  It feels like it would be good to have a library (accessible 
> from C and Python) which would have an API like "scan the barcode the user is 
> currently pointing the camera at and give me back something that tells me 
> what sort of barcode it was and the data it contains" (maybe with some sort 
> of callbacks to allow some user interaction if needed to give them 
> help/feedback with the scanning).  
>
> The subsequent processing (database, lookup, etc, etc.) is the sort of
> thing 
> that various people might create separate applications for, although it might 
> be useful to expose some useful APIs there as well: "lookup this barcode 
> number on Amazon", "save this barcode in barcode database called 'My Books'", 
> etc.
> 
> Is that how it works at the moment or something you are looking in to?

Yes this is indeed a good idea. At the moment it's not modular as
everything is mixed in, however the code is structured such that it
won't take long to separate out the processing from the video taking
from the gui etc.

The question is then how many separate layers? I guess a wrapper/lib to
process a barcode from an image buffer. An extra optional layer that can
be placed ontop of this to allow the user to see what they are pointing
at and to click "Scan!" (which we may do away with once the camera app
is opened up, then we can add the bottom-most layer as a plugin to
optionally analyse stuff taken with the main camera app). On top of
these/using these one can do the other stuff such as web-lookups,
databases, etc.

The web-lookups should possibly also be part of the bottom-most layer
though, or perhaps separated off into their own package as they will
generally be needed no matter the app.

Someone mentioned sending the barcodes out over DBUS, is this of
interest? Any use cases?

So I'm more than happy to do this (after I look at libgdigicam to work
out how to focus the N900's camera and turn the LED on), as long as
people want to use it, I don't want to waste time chopping things up if
no-one wants to use it afterwards.

Cheers,


Simon