Re: mbarcode
 

i dont know how can i post a code example its any barcode, i tested it in all sites (google, facebook, etc.) didn't work
i tried to do as Wikiwide said and i closed the auto focus and auto scan and it worked, i dunno if its better without the auto focus and auto scan or not

Re: mbarcode
 

Strange, I can't re-produce that at all. If I scan a QR code I get the results page with the QR code info + plugin buttons, then I close the results page, lock the device, unlock the device and scan an EAN and I get the EAN info + plugin buttons.

Re: mbarcode
 

Well certainly I'm curious to see why it won't work anywhere for you.

With auto-scanning set on, pressing the shutter button fully down (or the space bar) will give you the option to save the current frame to file. Otherwise there's a little disk icon in the top right-hand corner below the X (close) button.

Please attach an example of a barcode that isn't working for you.

Re: mbarcode
 

Ok, so I've added a function to decode and add MECARD/BizCards, but it's failing to add the contacts to the db. I need to work out whether it's possible to obtain more information from the QtContacts* stuff to work out why (and indeed if using the QContactManager even works under Maemo).

While doing this, I was thinking that it would be useful to let plugins signal the UI/user that they have (un)successfully performed their processing, using e.g. one of those information ribbons.

One option is to let each plugin do its own thing and generate an info ribbon as and when it wishes; another is to provide a slot/signal pair which the plugin can call with a message when it's done (or even while still processing). The latter case would mean we could specify how the messages appear and even keep a record/history, etc.

What are your thoughts Dragly as this would be a slight change to the plugin API?

Re: mbarcode
 

My thoughts on user feedback has been to use the ResultsWindow list. By changing the text/icon, the plugin can show the number of results, an error text etc. That is the reason why there is a timer in the ResultsWindow.

A ribbon is not a bad idea, but I'm afraid that this might spam the user if all the plugins start using this approach. The ribbons are limited to only show one at the time. Without a timeout, each ribbon must be clicked on to go away, and with a timeout the user might not see the info from the ribbon before it is gone.

I believe updating the plugin text or title is the best approach to give the user input on what's going on, unless we want this kind of input in other places than the ResultsWindow?

Re: mbarcode
 

Ah ok, that sounds like a good idea, ignore my previous ribbon thoughts :)

I've just had a look at the QTableView delegate paint callback and (not knowing any better way to do it) I suppose we could store the item number of the last pressed "button" and have the paint event paint that differently to indicate that their tap has actually done something. Any other ideas?

Re: mbarcode
 

No need, I just found my mistake. I had set the "selectionMode" of the QTableView to "NoSelection" some time long ago (for some reason unknown to me now). I have been suspecting the issue to be something like this, I just haven't had the time to figure out what I did wrong before today.

A new (untested) version with the fix has been pushed to SVN now. Hopefully this will give the user some more input.

Re: mbarcode
 

Of course the timer is just to allow slow plugins to decide whether they can handle the barcode payload and be added to the list, it's the paint event which asks each plugin for its icon/text/etc., so what one needs to do is to have the plugin alter its icon/text data to whatever is appropriate and then ask for the correct row of the QTableView to be re-drawn to update that information (e.g. calling update() on the QTableView or perhaps QTableViewItem or somesuch)

Re: mbarcode
 

Yes, you're right. My memory was wrong about what the checkPlugins() function was doing. Do you think that update() should be called by having the plugins issue an "imUpdated" signal, or should we periodically update the tableView? The former would probably cause less CPU time and power consumption.

Re: mbarcode
 

I'd go for something along the lines of an ImUpdated() signal as you say to save power on wasted updates, as many plugins probably won't even use this feature.

I've just tested the SelectionMode update and it works well, the only thing we probably need to do is remove the selection after some time (so it acts more like a button effect). Otherwise for e.g. the web search plugin, you return from the web search url list to find the row still selected.