maemo.org - Talk - mbarcode

maemo.org - Talk (https://talk.maemo.org/index.php)

- Applications (https://talk.maemo.org/forumdisplay.php?f=41)

- - mbarcode (https://talk.maemo.org/showthread.php?t=34996)

Quote:

Originally Posted by fms (Post 826647)

Two issues I have found in the current mbarcode:
1) It is not quite clear when mbarcode actually makes a shot. More than once I continued feverishly clicking the shutter button.

Atm it's scanning all the time and pushing the shutter button down half way makes it focus if the auto-focus is off. I agree though that we should have some kind of graphical and audio indication that something has been scanned successfully.

I'm also going to add the option to use the shutter button to focus then perform processing (for e.g. 3s after the button is pressed), which should save cpu cycles and make the normal display smoother (no need to have the decoder threads running in the bg all the time.)

Quote:

Originally Posted by fms (Post 826647)

2) Once you click on one of the plugins, the application seemingly hangs, and may continue in this state for a minute or so (while it is searching for your barcode). It should show the "busy" status instead (rotating thingie in the menu bar may do).

I noticed this today, but what I saw was that the list of plugins came up pretty quickly, but then when I was tapping buttons there was no graphical response (though eventually the plugin did open.)

This is especially odd as the plugin I wanted to use was the plain "display text" one, which should be pretty lightweight. I need to look into this as it's not acceptable to have delays like this.

The graphical response missing is probably due to something set up wrongly in the GUI. Either in the custom delegate used for painting, or just in the selection settings for the table view.

If there is a delay in other plugins than Informed Individual, then there is something seriously wrong. Maybe there is some lag after closing the pipeline? I'll try to look into it when I have the time, as well.

Quote:

Originally Posted by dragly (Post 827579)

An indicator is a very good idea. At the moment, there is also some problems with the list not giving the user any feedback when an item is actually clicked. I'll see if I can figure this out.

Most plugins react almost instantaneously on my device, but the Informed Individual server is down (the project is in an early alpha stage) and because of this, the plugin uses a huge amount of time to wait for the request to the server to time out. So if this is the plugin in question, I experience the same delay without any user feedback, as well.

Depending on the complexity of the plugin, we might need to thread the plugin callbacks, especially for plugins that perform web-lookups.

If I remember correctly, the network requests made in Qt are done in a separate thread. That's why you need to connect a slot for the network reply, whenever that returns. The problem with the Informed Individual plugin is that it currently does not give any user feedback before it receives a network reply, but it does not block the GUI, though.

In other words, there is no GUI-blockage when you hit the Informed Individual plugin. Just try to go back to scanning after pressing the plugin button.

On the other hand, making the clickAction() of a plugin into a threaded signal/slot system might be useful to avoid plugins locking up the whole application.

As an aside, I've just pushed the skeleton of a plugin to handle Python plugins. I need to push PythonQT to extras-devel asap and then work out the structure of Python plugins and fill in the useful code, but I have at least started (finally! ;))

The reason for using a plugin to host multiple plugins is to stop it being necessary for people to include the additional PythonQT startup overhead and dependencies unless they are using a Python plugin.

Anyway, I'm working on it :)

Just looking at the code to add in the alternative shutter button action and wondering how much of the startup time is due to using OpenGL?

Dragly have you done any benchmarking? Any other thoughts about getting a functional UI up faster?

As another aside, I wonder if we should load the plugins in a thread/in the bg somehow to prevent the slowdown that will probably occur when they are loaded the first time a barcode is scanned?

After installing Mbarcode to my N900 the camera would not work. I only get a errormessage internal error, camera will be closed.
Had to uninstall mbarcode and addons.

Quote:

Originally Posted by protrek (Post 828779)

After installing Mbarcode to my N900 the camera would not work. I only get a error message internal error, camera will be closed.
Had to uninstall mbarcode and addons.

Strange... I have mbarcode 0.2.2-4, the latest version, and experience no such problems whatsoever.

Quote:

Originally Posted by protrek (Post 828779)

After installing Mbarcode to my N900 the camera would not work. I only get a errormessage internal error, camera will be closed.
Had to uninstall mbarcode and addons.

Probably not an mBarcode problem tbh as it works for everyone else. Rebooting tends to fix a non-behaving camera.

If it really does seem to be linked to mBarcode, I'd be interested to see the output of the camera app from the command line when you try to run it, and also the dmesg and DSP logs.

Quote:

Originally Posted by lardman (Post 828755)

I've been looking at FCamera, which uses nice overlays for the camera controls and histogram but doesn't use OpenGL. I'll try converting the UI to use plain Qt overlays and see what the performance is like.

Edit: OTOH it may use OpenGL itself, in which case I won't bother :) - I'll look and see!

No, it doesn't use OpenGL (so there's still the chance it will be quicker). Instead it uses the overlay layer provided by the framebuffer hardware. I suppose it should be possible to encapsulate the overlay stuff in a class and then be able to easily swap between OpenGL and framebuffer overlay. The FCamera people have wrapped the overlay stuff in a class - see OverlayWidget.cpp in the FCamera Garage project.