Qreator as decoder
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
- Started by
- Completed by
Related branches
Related bugs
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:/
- QML as a Qt C++ plugin: https:/
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://
[2] http://
[3] http://
[4] https:/
