Qreator as decoder

Registered by David Planella on 2013-05-29

So far Qreator has served the needs to create QR codes well. In the mobile world, though, code creation should be a secondary feature, with the focus being on implementing image capture and decoding, ideally for both QR codes and barcodes.

Blueprint information

Status:
Not started
Approver:
None
Priority:
Undefined
Drafter:
David Planella
Direction:
Needs approval
Assignee:
None
Definition:
Discussion
Series goal:
None
Implementation:
Unknown
Milestone target:
None

Related branches

Sprints

Whiteboard

The main features we need to implement to achieve this goal are image capture with a camera device and decoding.

# Image capture

From initial tests, it seems that capturing images is well supported in QML through the Camera interface, and relatively trivial to implement. As an added benefit, this works both on the desktop and on mobile devices (tested on a Galaxy Nexus).

# Decoding

After some research, it seems that the de-facto Open Source decoding library is ZXing [1], which Google also uses. It has bindings (ports) for more languages than we actually need, but there are no official Qt (C++), QML or JavaScript ones.

However, there are indeed unofficial ports:

- JavaScript: https://github.com/LazarSoft/jsqrcode
- QML as a Qt C++ plugin: https://projects.developer.nokia.com/QZXing

While JavaScript would get us 90% of the way in the least time, there might be penalties in terms of performance. Also, I wasn't too convinced by looking at a glance at the code.

I've started investigating the C++ plugin way, so that once built we can use it as an installable package that we can access easily from QML. The original code needed porting to Qt 5.0, which I've gone and packaged as well [2]. However, I got stuck on this issue [3]. I believe if that can be solved, the plugin way might be the most robust way to implement decoding.

# Additional steps

After the decoding of the QR code, there are two missing steps: interpretation of the data and the according action. As an example, the data "mailto:<email address hidden>" needs to interpretated as an email address data type, and the following action should be to open the default email app with a prefilled new email, ready to send.

We should at least be able to respond to the following data types:

URL -> open browser
email -> open mail app (prefilled address)
sms -> open message app (prefilled number and message)
call -> open phone app (prefilled number)
location -> open map on location / direction to location
contact -> add to contacts app
event -> add to calendar app

A list of typical formats can be found on the zxing site [4].

All of these actions should require user confirmation.

[1] http://code.google.com/p/zxing/
[2] http://bazaar.launchpad.net/~dpm/+junk/qzxing-plugin/files
[3] http://stackoverflow.com/q/16821561/1049318
[4] https://code.google.com/p/zxing/wiki/BarcodeContents

(?)

Work Items

This blueprint contains Public information 
Everyone can see this information.