Author: Johan Thelin

When building Harmattan apps using Qt Creator, it is important not to have dashes in your project name. If you do, the generated desktop file will refer to foo-bar, while the app binary and icon will be named foobar. It is a simple fix, but can be confusing at first.

Symptoms: app starts when launching from Qt Creator, but icon looks odd and app cannot be launched on the device.

As Qt 5 approaches alpha, it is more and more interesting to try using it outside the comfort of developer machines. For that, packages are needed.

Thanks to vgrade I found the qt-spec-effort project on Gitorious. This git contains a nice script that populates an OBS with the Qt packages. Perfect for my needs. I had to employ some minor tweaking to get things going, so my clone can be found here.

One thing that possibly could affect Qt 5 is the version of XCB, the new X protocol C bindings. When upgrading the existing packages for libxcb and friends I ran into a split package. Apparently, xcb-util was split into five packages (xcb-util, xcb-util-wm, xcb-util-renderutil, xcb-util-image, xcb-util-keysyms), so the packaging turned out to be a bit more tedious than expected. Still, the spec-files are available from the xcb-spec-effort git that I setup. The only consequence of this was that I had to be more specific when specifying dependencies for Qt 5’s qtbase (it is all on Gitorious).

So, now, all I need is a good way to measure and optimize QML performance. The swaplogger tool serves the first purpose (spec file in this clone). Now, all that is left is the optimization part :-)

I visited OpenSourceDays 2012 this weekend. I did my presentation and met some people, but could not attend any other sessions. This was part due from the site being out of power when I got there (talk about Murphy at a large scale) and part because I wanted to enjoy beautiful Copenhagen with my family.

In my presentation I wanted to discuss how to approach the problem of building a run-time environment for a QML user experience. The choice is (as always) between time and quality. In this particular case, quality means how free the user experience designer is from the run-time implementation.

After the talk, I enjoyed a discussion with Mario Boikov. I argue that it is ok to use root context properties, i.e. global singleton variables in QML-space, to share states. He argued that presenting everything as QML registered types that QML instantiates gives better QML. I agree and disagree, as always ;-).

By using root context properties, it is clear to QML that it is a singleton instance. It is also a very handy way to expose plain QObjects to QML. Just add the odd Q_PROPERTY and Q_INVOKABLE macro and add it.

By exposing state-representing objects as registered types, one has to handle the singleton back-end (if it exists) through a wrapper class registered to the QML type system. This adds complexity on the C++ side. This, I feel, is ok, as the C++ developers are the ones with system knowledge. Any complexity related to technology should be handled here. From QML, this approach gives you prettier bindings. You can find a property of the service to something, and you can avoid the Connections solution to reacting to signals.

What you do lose on the QML side, is the clear message that the particular object is a singleton. You also (potentially) introduce allocations and deallocations of the wrapper object. This shouldn’t be an issue, especially not as such a QML design would trigger those either way. Still, as an old school embedded engineer, memory fragmentations is a scary thing.

QML is a wonderful thing, but the language and tooling are new to us all. I suppose discussions as the one above will lead to some sort of best practice being established. In the mean time, lets benchmark and compare notes. What gives the prettiest code, where do you lose performance, what did the Trolls intend for us :-)

Qt does not sell mobiles. As a consumer, Qt is a technicality. Right now, the experience and availability of apps sell phones. Qt is just a tool for us developers to implement those experiences. Despite this, it is interesting to compare the Nokia N9 and the new WP7-based Lumia handsets. The market’s reaction to both, and the irony of it all.

Sweden is a highly developed smartphone market. Almost everyone has a smartphone. Flat rate data subscriptions are cheap. Both N9 and Lumia are sold here, and are advertised.

The reviews are interesting. In mobil.se’s comparison, the N9 lose out because the platform is bound to die, thus have fewer apps. In the same organisations yearly awards, the N9 win three out of four applicable categories (the Sony Ericsson Mini Pro won the value-for-your-money-award). The N9 also went straight to the top of the selling charts at katshing.se, and in the telekomidag.se review of Lumia, the final words praise the N9 “Sister model N9 with MeeGo was a (albeit late) eye-opener, for Lumia is feeling more of oh well-character. Skilled in every way – but we have seen most things before.” (google translation of “Systermodellen N9 med Meego var en (om än för sen) aha-upplevelse, för Lumia blir känslan mer av jaha-karaktär. Kompetent på alla sätt – men vi har ju sett det mesta förut.”)

Following this trail, the latest sad figures from Nokia report that things aren’t going that well. Telling your customers and employees that your current unique product is dead, then delivering a mainstream product later does not help improve business. Bloomberg has looked at various analysts’ estimations of sales figures, and they estimate 1.4 million N9 where sold 2011, while the Lumia is estimated to have sold 1.3 million (estimates range from 800k – 2M).

The interesting part in all these comparisons is that the N9/MeeGo platform is not being pushed by Nokia. They do not want to sell it. The Lumia, on the other hand, is being pushed by the biggest marketing budget Nokia ever has spent on a single product. The Lumia series is being expanded, apps are emerging.

I am sure that Nokia/Microsoft will succeed. I had a VHS system at home, even though Betamax was technically superior. The cost for success will be to turn Nokia from a leading brand into a mainstream supplier, no more important than HTC or Samsung. Sad for Nokia, sad for Finland, sad for what could have been for Qt. Launching N950 alongside N9 and following up with multi-core models would had been great. Also, seeing that MeeGo Harmattan more or less was Maemo with Qt, Intel’s drop-out would not have been the end of the world.

Still, from a Qt developer, this, in combination with the openly governed Qt Project means that Qt will stay a cross platform tool. The risk of seeing it being sucked into a life as a (great!) single platform is no more. Qt/iOS, Qt/Android and Qt/MeeGo give a bigger target area than WP7 has. And if the WP8 platform is to follow desktop, Nokia just jumped from one burning platform to another, since they are going HTML5.