Re: mbarcode
 

This is a great program and thank you to all of the talented people who are working on it.

If I recall correctly, an early version of mBarcode had full screen scanning as well. I was not really crazy about it but I see the benefit of being able to scan a longer code if necessary.

What I think might be nice is some kind of overlay (like a thin horizontal red line - maybe configurable on/off) in the scan area that would at assist with barcode positioning as well as a 'beep' (also configurable) if the scan is accepted.

Re: mbarcode
 

In low light conditions, especially when the camera is close to the barcode (because it's small) you often get the case where the autofocus events occur pretty much simultaneously.

Now this might be because the timer runs independent of the autofocus time, so perhaps we should start the timer after the last autofocus event (though I need to check and see that this theory is true).

Alternatively we should do some intelligent delay time altering depending on whether the autofocus has failed X times, etc.

In the meantime do just get rid of the button (but comment out the callback) and then we can have a look at these edge cases as and when the occur.

Re: mbarcode
 

Looks good :)

You mean a vertical line that scans across the screen? Sounds interesting, as long as it doesn't take too much overhead.

Edit: we could make it red and have a Cylon noise along with it ;) Either that or Kitt :)

Re: mbarcode
 

Yes good question. Would we prefer to leave the camera view open? Perhaps when you click "Stop Scanning" it should open up the history list, then when you close that it starts scanning again automatically? I don't know really.

Perhaps we should involve a UI person at some point?

This is a difficult one - it's certainly desirable for the initial screen to be able to show data that has been looked up using the barcode, but as you say, we don't want network startup/general delays to impact this.

I wonder if one option would be to present some placeholder text, via the callback, e.g. ("Amazon lookup, finding price...") then to allow each plugin to go away, do some processing and then be allowed to update the displayed data if the results dialog is still present?

This would have to be an optional thing, as otherwise we'll have lots of plugins doing web lookups which might get expensive (another setting for the Settings menu I think).

Thoughts?

Re: mbarcode
 

On behalf of everyone, thanks :)

Do you mean longer barcodes? Just hold the N900 further away from the barcode so it fits in the frame. I had to reduce the field of view of the camera to increase the barcode size in the frame with the camera held further away as the macro-mode/close-up autofocus was pretty shocking.

Afaicr, there's no requirement for any positioning (whether vertical/horizontal) or angular, though obviously having it the right way up will work faster as it's checked first, so this wouldn't serve any real purpose (except to let people know it's a barcode scanner perhaps?)

Re: mbarcode
 

Ah, dannycamps' comment made me think, the aspect ratio of the N900 screen is different to the camera data we are currently using (640x480 iirc).

How does the camera app deal with this (I'm guessing the output from the camera is 1.33333 rather than 1.66666, but perhaps I'm wrong).

If it is in fact widescreen (the camera), then I suppose we could request a larger frame (wider) from the gst pipeline and indicate to the user that the edges won't be used for scanning by some bars of some kind.

We'll have to see what the camera view looks like with Dragly's changes.

Re: mbarcode
 

Well, notice that the widescreen setting on the camera has a lower pixel count than the standard aspect. I suspect that it's chopping off the top and bottom parts, and enlarging the image.

One option would be to have a black bar along the right side where the icons are.

Re: mbarcode
 

Yeah, might not look so pretty then though ;)

Currently the full-frame camera image is trimmed so that we remove 25% from the top/bottom/right/left, so I suppose I could change the pipeline so that the data going to the display widget doesn't have the sides trimmed, while the data going to the decoders has all 4 sides trimmed.

Edit: FYI, the reason for the trimming is that we don't need/want high res data (as it then takes the decoders longer) and we also want to allow the N900 to be held beyond macro range so the autofocus works (better...). Therefore rather than just scaling the whole frame (which didn't work very well in the first versions of GTK+ mBarcode) I elected to trim the sides off. Seems to have worked pretty well so far anyway

Re: mbarcode
 

I was just pointed to an online QR code generator; it appears that (at least some versions of) Android support using a QR code to communicate wifi settings.

This is one of the best uses for barcodes that I've heard in a while; I'm going to see how easy it would be to implement in Maemo 5...

Re: mbarcode
 

Sounds cool :)