Following Nokia’s announcement that the future of all Symbian and MeeGo development will/should be based on Qt, Qt Quick and QML, I have been evaluating Qt Quick, QML and the latest mobility APIs for use on a client project I will be working on very soon.
Previously when creating Qt UIs, you had to either use Qt QWidgets or build your screens on top of QGraphicsView. QWidgets are the lowest common denominator in Qt in that they work on all Qt platforms (Windows, Linux, Mac, Symbian, MeeGo). However, the user experience is very poor, especially on touchscreen phones. You don’t get the phone’s underlying look and feel and hence this method of development isn’t really acceptable for today’s applications.
QGraphicsView is newer and allows use of things such as transitions and animations. You still have to build your own controls (buttons, lists, edit boxes etc) on top of QGraphicsView and for this reason it can take a lot of effort to create an app. Orange Wednesdays is an app that was produced this way.
The very latest option being promoted by Nokia is to use Qt Quick and QML. This is built on top of QGraphicsView and allows for declarative (textual) based descriptions of screens. It’s possible (yet slightly convoluted) to communicate back and forth with Qt (c++) for times when you need to do more than QML provides. The latest Mobility APIs (1.1) also expose bindings that allow QML to access phone-specific features. However, Qt Quick and QML are still work at a lower UI level than many developers might expect. For example, you have to deal with things like rectangles and regions as opposed to buttons and text boxes. There’s a project to create higher level Qt Components but they aren’t suitable for commercial use at the moment.
Unfortunately, I haven’t, as yet, got the latest Mobility APIs (v1.1) working under emulation. They are supplied in source form and you have to first build them. I didn’t get that far and instead ended up with an error:
c:\qt-mobility-opensource-src-1.1.0\src\mobilitysimulator\mobilityconnection_p.h(50) : fatal error C1083: Cannot open include file:
‘private/qsimulatordata_p.h’: No such file or directory
I question why developers have to compile these APIs at all. Why can’t they be pre-built and included (and upgraded) via Qt Creator?
While Nokia’s Qt developer story, as told by Nokia executives, might seem ok at a high level, when you dig deeper there are some big issues for people wanting to develop now. The Qt tools have been a ‘work in progress’ for a long time now and it’s not possible to create applications with the ease provided by other platforms’ (or even Symbian Carbide) tools.