Where are those mobile Qt apps ? (Part 3, Resolution)

After a short historical overview and a short list of growing pains, in this, third installment of the mobile Qt app story, I will focus on what boulders remain in the path of widespread adoption of Qt among app mobile developers. Most of the technical groundwork has been laid down, but to reach a final resolution, it needs to include a bit more than just a healthy base.


Decouple Qt releases from firmware releases

As seen from the infamous PR1.2 delay, a coupled-with-the-firmware release cycle is detrimental to the platform. If multiple devices are on the market, it would mean instant-fragmentation as developers would have to code for the Qt released with the last firmware. This is eating Android alive, too, as various handsets have different upgrade cycles. A separate distribution mechanism HAS to be employed. It will be tricky as with MeeGo and Symbian^4 Qt is part of the OS and many teams will be reluctant to bet firmware functionality on the backward compatibility of Qt. But that is not the only thing that can cause fragmentation if it isn't true that...

One mobile widget framework is enough


I harp about this regularly (and will continue to do so until I get good news from an official source :), the option to have separate widget frameworks for Symbian (Orbit/uiemo) and MeeGo (DirectUI/MeeGo Touch Framework) is something that is completely against what Qt is trying to accomplish by bridging the two OS-es. 

All you bases are belong to us

Qt is almost a country of it's own, addressing (or having a development version that addresses) various aspects of software development, both mobile and desktop. However, there is one thing where it is sorely lacking - the wizz-bang games department. Yes, QGraphicsView and 3D enablers are cool and all, but that is not enough (even with QML and UI scripting). It would certainly be an overkill and unnecessary delay to implement a complete game engine in Qt, but there are alternatives - make a Unity3D port, or, better yet, in the spirit of open source, sponsor Ogre binding (and GLES) development for Qt, with the necessary physics libs.

Build it and they will come - Ovi and devices

Professional mobile developers can and will materialize only after the market for the Qt apps materializes. The prerequisite for this is that Qt gets a first-class treatment in the Ovi store, and the QA process is not a hit-and-miss, something that developers are guessing about. Once the Ovi store really starts accepting Qt apps en masse, the question turns into how many devices can be targeted via Qt. I can hear you say "well that's like almost all Symbian handsets in the last 2-3 years". Yeah, but... 


Market share is not necessarily mindshare

Devices that can be retrofitted with Qt already exist in the (tens of) millions range. However, these devices are mostly low to midrange devices as there were no runaway Symbian successes in the high-end segment for a while now. It will be hard to convince people to target a market, no matter how objectively big if they believe/see it as a relic, which means... 

You've got to be cool

The vehicles for the Qt platform need to be cool and carriers of high tech. This is the wave Android is riding in 2010. Now, the best way to do this is having iconic devices (iPhone killers if you wish), but this is not ONLY about devices, it's about how you handle your technology in general, your devs, your community, blogs and everything related to it. Qt has to be perceived cool, a must-have even by non-tech people, not just a sticker on the corner of a box and something geeks nod over on irc. It IS the differentiating factor. Take for example the happenings of last week in the Nokia N900 land. A triple-release is done - preview of the Qt Web Runtime, a new version of Qt Mobility and the super-cool fcamera project. This triplet just oozes with tech-cool demo potential, but it just isn't leveraged, hardly getting even a blog post. Instead there is a campaign and an 'exciting news' about Ovi doing a comic (I'm sure it will be good, but... ). This points to comms issues, but also lack of

Communication/Community Focus

While I don't know how many different communities and aspects of Qt should there addressed separately, I'm pretty sure we are already overloaded, even before the hordes of the new Qt developer generations emerge. There is the Qt Developer Network, then we have Forum Nokia (home of the Nokia Qt SDK), followed by a more specific MeeGo community that is vested (well, at least the handset variant) in Qt, and the same will be true for Symbian. OTOH If you want to publish/talk about Qt development on currently available devices, you should go to maemo.org. While in community waters, we should also mention Qt Centre. Quite a handful of forums, mailing lists and irc channels to follow, and I have not even talked about communities focused squarely at end-users ! Speaking of end-users, some people who even knew about those Qt/fcam releases I mentioned above were quite discontent, because there is/was no concept of...

Control and drive expectations

The 'other' platforms and ecosystem have built up and trained users to expect certain things in a certain way, and if they are not educated, they will not understand what is going on and will easily dismiss even good news when it is not is a form they expect it in. See the above - new releases of QtMobility, WRT, etc were not treated by many as real news or support by Nokia for the N900, even though they were done by official Nokia teams. The concept of the 'holy firmware release' is still strong, because people don't understand the concept of libraries and components (as that is not how most other platforms operate).


Those would be my major points, and while they might sound a bit grim (some not even related to Qt itself), I don't think they are insurmountable at all, it just takes a little effort (some already underway) and presto, the arid Qt mobile app landscape can bloom like a savanna after a rain.

Where are those mobile Qt apps ? (Part 2, Adoption)

After my last blog post that discussed the Qt toolkit's history, present and future in the Nokia ecosystem, in this second part of my blog series I will talk about the problems of Qt adoption among developers so far and the effects these problems had on (the lack of) mobile Qt applications today.

This will not be an article about the flaws of C++, bloatedness of frameworks and similar issues. Sure, some people prefer other languages, other frameworks, or have a personal beef with Qt, but that is a different story. Here, I will talk about the WAY things happened, are happening and what could have been better handled - albeit from a Qt angle.


Are we there yet ?

Qt was originally a desktop application framework, but has been dabbling with embedded applications way before Nokia took over. However, the focus shifted dramatically and Qt (and derived technologies) went to overdrive, introducing new (and exciting !) technologies and approaches by the boatload (see MeeGo Touch, QML, etc). This not unlike what Android was/is doing - a forced growth where the race is on to pump R&D *before* the large footprint of deployed tech becomes a maintenance nightmare. On the flip side, this makes developers reluctant to write for *current* stable releases as stable is a mostly-working-kind-of-stable and they know not only there is something new and shiny coming up (it always is), but that it is coming *soon*.


Desktop vs Mobile

The long and successful history of Qt means there are (tens of) thousands of developers fairly familiar with Qt. However, this does not translate to mobile applications galore for several reasons. First of all, those people need to be motivated to write high quality mobile apps. They will not start to develop for mobile devices just because they are there, not any more than an enterprise Java developer would drop everything to make midlets. Sure, if someone is already familiar with a technology, that person will likely use it in it’s hobbies too - and that’s it, "desktop Qt people" are NOT the base that will spawn the bulk of serious mobile Qt developers/companies - those people will come from people with existing mobile background or interests. This seems to be slowly being realized now, as porting tutorials for Android and iPhone started appearing on Forum Nokia. This is an important shift, and while might be characterized as aggressive, it’s exactly those developers that need to be targeted to get the Qt ecosystem on the mobile industry radar.


The big GTK+ migration

Since July 2009, it has been known Qt will take the place of GTK+ in Maemo/MeeGo. To be precise, this is not as much about GTK+ itself, but about the GTK+ based Hildon application framework, initially developed by Nokia. It is understandable that such a major change touches on many existing developers and that such transitions are always difficult to manage. However, there were a lot of indecision and mixed signals from both Nokia and the community as to what exactly should be done "for now" and "for the future", what is or isn’t available in Qt and just how important it is for Qt to mimic/fit in the existing, but deprecated Hildon environment. In retrospect, once the strategic choice of going Qt was made, the push for Qt should have been much stronger, helped with migration plans/tutorials for existing developers.

 The big Symbian migration

Almost literally the same applies to Symbian people. While nowadays it will be hard to find large gangs of fierce AVKON supporters and the public/private API approach of Symbian, there is still a significant "why do we need Qt" notion. It has to be made clear AVKON is dead and, again, just as with GTK, handing out Qt tutorials that start from scratch will not help as much as good, targeted migration plans/tutorials for Symbian people. Just putting Qt on a Symbian handset preinstalled will NOT be a sufficient motivator for existing developers.


New vs existing developers 

As seen from my stance in the "desktop vs mobile" section, it is clear why I think people already doing or interested in apps for mobile devices are important, and there has simply not been a widely successful effort (yet) to help ease people into Qt’s way of doing things. This is well illustrated in the experience with Maemo - most Qt apps were written by people who came to Maemo *first* and *then* started doing Qt.

You have Python - use it. 

There are two Python binding projects available for Qt, both open source but neither have the status of being an "official" Nokia binding and Ovi not supporting Python apps at all. Again, from Maemo experience we see that there is a huge interest in these because even with the limited documentation and support available the number of Python apps is comparable to the number of pure C++ Qt apps due to the low entry barrier of Python.

TIMTOWDI*

Some people will snarl at this, but.. there are simply too many ways to do things. Or, rather, there aren't (sufficiently) recommended ways of doing things. Quality training material is starting to appear, but any time somebody asks how do I do a GUI there needs to be a longish discussion as to what version is being targeted, what tools are acceptable, etc, etc. If there are 5 ways of popping up a Hello World dialog (many of them quite 'old school'), know that people WILL get lost or at least discouraged when they try do merge docs from all over the net.


Show me the money

As seen/heard from many professional (as in for-money) developers on various Maemo forums, they do not really care about Qt. Sure, it’s cool and a lot friendlier than some previous approaches, but the ultimate test for them is the market. If a super-appstore existed and it required you to code in assembler, it wouldn’t matter much, these guys would just bite the bullet and do it that way. The morale ? Technical merit seems to influence adoption rate a lot less that many believe and the primary aspect are really cost and perceived benefit. Let me emphasize - this only applies to large-scale commercial development, FOSS and hobby coders *will* be affected a lot more. And while we are talking about money...

The closed door

One of the lures of application stores is that they are simple to use, accessible to one-man-show developers, and, well, 'just work'. Unfortunately, Ovi was not really ready for the Qt apps (or the N900) in the planned 'end of 2009' timeframe - whether they had more important things to do or more important holes to fix, I wouldn’t know. In any case it took a hefty extra 6 months until you could actually submit Qt applications to Ovi, and the Ovi QA process for these is still trailing the community QA process in many ways.

Chuck Norris releases PR1.2

Well, at least for onlookers it felt like it would take Chuck Norris' superpowers to get the infamous PR1.2 firmware released for the N900. This alone was not a problem, firmware delays happen, but the bundled nature of firmwares meant that Qt4.6 that was ready at the end of March could not be distributed until the end of May, a 2 month delay for no reason at all. On a side note, due to bad communications, this issue caused an outage of several weeks for community developers unlucky enough to depend on packages that have been changed in the update. While this particular incident was Maemo-specific, the Symbian counterparts are not immune to such risks.


So, does all this mean Qt is doomed, the future is grim and is all hope lost ? Not at all, as you might have noticed, many of the issues are growing pains, have already been resolved, or are at least in the phase of being taken care of. The change that is going on is really huge, a lot bigger than a lot of people realize, however, it would be not be sincere to say all will be peachy from here on. Even though the time for reaping the benefits is finally closing in, there are a few points that need to be addressed before Qt becomes a no-brainer for both commercial and community development and all those apps start pouring in. Tune in for for the final, third part of this series to see what these are.

So, where are those mobile Qt apps ? (Part 1, History)

As part of a testing and compatibility effort, Nokia announced Qt to be officially available on Maemo 5 (i.e. the Nokia N900) on the Maemo Summit in October 2009. A lot of time has passed since then, and despite the sizeable Qt developer community and popularity of Qt on desktops, the number of Qt applications remained fairly low. This is true for both among the (admittedly few) commercial apps and in the (thousands strong) Extras community repository. In this three part blog series I’ll try to analyze what are the causes for this shortage and what needs to be done to remedy this situation lest it continue onto MeeGo and future Symbian versions.

This series consists of three parts (yes, I finally realized my posts are too long) :

1. History - the timeline of Qt with regard to Symbian and Maemo/MeeGo
2. Adoption - describing what problems have hindered a "more than words" Qt adoption so far
3. Resolution - what are the remaining logjams and how to break them

As described above, in this part, I’ll write about the history of the Qt timeline in Maemo/MeeGo in order to gain some perspective:

• 2008 Jan - Nokia buys Trolltech (makers of Qt) 
• 2008 Apr - Qt support for Maemo is announced
• 2008 Oct - First Android handset released
• 2008 Dec - Qt4.5 becomes available as a community edition for Maemo 4.1
• 2009 May - Symbian^4 deprecates AVKON and carbide C++ in favor of Qt4.6 and the Nokia Qt SDK
• 2009 Jul - Qt4.6 is announced as the base application framework of Maemo 6 (Harmattan)
• 2009 Oct - Official Qt support (4.6 for 2010Q1) announced for Maemo 5 on the Maemo Summit, and beta made available
• 2009 Nov - The N900 ships with the not-overly advertised community Qt4.5 version, first post-ARM11 Android 1.6 is released
• 2010 Jan - Stable Python Qt bindings are released
• 2010 Feb - Nokia and Intel announce MeeGo, Qt4.6.2 released with Smart Installer beta allowing install of Qt apps to existing S60 devices 
• 2010 Apr - The Nokia N8 is announced, the first Symbian^3 handset that will ship with Qt4.6 preloaded, bridging old AVKON based S60 and the future Qt based Symbian^4
• 2010 May - After much delay, the PR1.2 firmware for the Nokia N900 is released with Qt4.6.2
• 2010 Jun - The Nokia Qt SDK is released and Ovi store starts accepting Qt apps 

The Qt toolkit is one of the pivotal points of Nokia’s future strategy as it will be the base of it’s MeeGo handheld user experience and also the umbrella that will unite Symbian and MeeGo from an application developer perspective in the future. We can see that this is no short term plan - it took quite some time to arrive here. Just to put things into perspective I included a few Android events. This should also make it clear how "new" the Android arrival is and how it hardly fits the Qt strategy on the platform level - though I would still like to see Qt apps on Android.

In any case, seeing the timeline it is obvious that the Qt strategy was not a whim, it was a broad, consistent strategy. Qt has come a long way, it has been available to developers living on the mobile edge for well over a years (and two decades for those that are familiar with Qt from the desktop). It fought it’s way to actual devices and stable repositories (an install base of several million handsets via the Smart Installer and the N900 since PR1.2). Ovi now accepts Qt apps. The Nokia Qt SDK is released with the nifty QtCreator IDE largely reducing the pains of the powerful-but-linux-guru-oriented scratchbox environment of the Maemo SDK. The Qt API is a lot friendlier than the AVKON APIs or the generic rag-tag Linux APIs ever were. There are already thousands of developers (both FOSS and commercial) with a lot of previous Qt experience. Qt is touted as the future of all Nokia smartphones. We should be swimming in cool Qt apps, right ? Well, sadly, as many N900 owners are painfully aware, that is still not quite the case, and while there are a few community efforts and the telltale commercial app, it’s far from a landrush. In this blog post I have outlined the Qt’s history, it’s promise on mobile platforms and all the good stuff. If you want to know where the sand is slowing the gears down and what both Nokia/Intel and the community can do to unblock the cogs, check back in a couple of days for parts two and three !