Notices


Reply
Thread Tools
Posts: 86 | Thanked: 54 times | Joined on Mar 2010
#361
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.
 
Posts: 2,102 | Thanked: 1,309 times | Joined on Sep 2006
#362
Originally Posted by joshn53 View Post
I'll happily cave on this one, but I can't think of a time when a user wouldn't want autofocus. Is there really a need for the user to manually control the focus?
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.
 
Posts: 2,102 | Thanked: 1,309 times | Joined on Sep 2006
#363
Originally Posted by dragly View Post
Here are a few mock-ups of the new design/workflow I'm considering. All input is greatly appreciated!
Looks good

Originally Posted by dragly View Post
I'm also considering adding one of those "scanner lines" to give the user an impression that something is going on (i.e. the application is scanning, not just viewing the camera).

What do you think?
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

Last edited by lardman; 2010-07-09 at 08:40.
 
Posts: 2,102 | Thanked: 1,309 times | Joined on Sep 2006
#364
Originally Posted by joshn53 View Post
Wow, those mockups look really good! A couple of comments:
* What happens when you click "Stop Scanning"? It seems like if the camera is the main background, clicking Stop goes ... nowhere?
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.

Originally Posted by joshn53 View Post
* The icons don't seem very intuitive to me, but they're certainly better than nothing.
Perhaps we should involve a UI person at some point?

Originally Posted by joshn53 View Post
* I'm concerned that displaying the data associated with results (e.g. 7/10, $1.32, etc) will be too slow, since it may need to do network communication, etc. Could that be relegated to the next screen?
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?
 
Posts: 2,102 | Thanked: 1,309 times | Joined on Sep 2006
#365
Originally Posted by dannycamps View Post
This is a great program and thank you to all of the talented people who are working on it.
On behalf of everyone, thanks

Originally Posted by dannycamps View Post
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.
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.

Originally Posted by dannycamps View Post
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.
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?)
 
Posts: 2,102 | Thanked: 1,309 times | Joined on Sep 2006
#366
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.
 
Posts: 111 | Thanked: 80 times | Joined on Oct 2009
#367
Originally Posted by lardman View Post
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).

We'll have to see what the camera view looks like with Dragly's changes.
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.
 
Posts: 2,102 | Thanked: 1,309 times | Joined on Sep 2006
#368
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

Last edited by lardman; 2010-07-09 at 12:57.
 

The Following User Says Thank You to lardman For This Useful Post:
Posts: 111 | Thanked: 80 times | Joined on Oct 2009
#369
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...
 

The Following 4 Users Say Thank You to joshn53 For This Useful Post:
Posts: 2,102 | Thanked: 1,309 times | Joined on Sep 2006
#370
Sounds cool
 
Reply

Tags
barcode, camera, mbarcode

Thread Tools

 
Forum Jump


All times are GMT. The time now is 00:46.