The Qt promise and what Maemo 5 needs

(tl;dr: Nokia should provide updated Qt packages as official SSU for Maemo 5.) Before I start, here are some facts (correct me if I'm wrong):

• The N900 runs the Maemo 5 operating system
• Maemo 5 received some updates (the latest one being PR1.3)
• We don't really expect PR1.4 to come out any time soon, if at all
• The MeeGo Handset images from meego.com are inferior to Maemo 5 and not a replacement (and never will be)
• The MeeGo operating system on the first Nokia MeeGo handset will have a proprietary UX and proprietary apps, and won't be available for the N900

In summary, it means: We are stuck with Maemo 5 on the N900. And that is a good thing! Lots of useful apps, a helpful community (if you subtract the trolls) and a polished OS. Sure, there's room for improvement, and lots of open bugs that should be fixed, but that's another issue (which will ideally be solved by open sourcing closed components with bugs that Nokia isn't interested in fixing anymore and by the Community SSU). This one is about Qt.

Two days ago, an e-mail was sent to maemo-community, proposing a "community service pack", which basically is a big pile of workarounds. Read my response for some initial thoughts.

When Qt arrived on Maemo 5, the promise was two-fold:

• Write your apps in Qt and you're ready for MeeGo (apps written now will run on the platform released in the future)
• Maemo 5 gets Qt support, so MeeGo apps will run on the N900 (apps written in the future will run on the platform released now)

It turns out that the first one will probably hold true (surely with QML, maybe even with QWidget), while the second one is doubtful, as Maemo 5 has only got Qt 4.7.0 through the official channels (PR1.3), with no real official update in sight. If you use QML, use QtQuickCompat as workaround ("Qt Qml plugin that reregisters all “Qt 4.7” types in the “QtQuick 1.0” namespace … useful if you’re forced to stay with 4.7.0 (e.g. on N900), but still want to use the new namespace.").

There is also a real bug (yes, a bug!) in Qt 4.7.0 on the N900, and the fix isn't released as update - it's a new package: libqt4-bearer-hotfix ("This is a hotfix for the broken ICD package in Qt 4.7.0. It can be removed once Qt mobility 1.1 is released."). Now, the proposed "Community service pack" would combine all these fixes into a single dependendable metapackage (yes, a new one). It becomes the "Unbreak my Qt" feature that every app developer has to depend on and specify in the packaging.

This is wrong! No developer targetting MeeGo who has not heard about Maemo 5 will go through all those ugly workarounds and spend a week fixing things up for Maemo 5 just so that the app works. Now imagine what would happen if the first MeeGo device also introduces such kludges once it falls out of its support life cycle. Or what if the problems on Symbian are similar, and developers have to special-case things there. Not only for Symbian^3, but also for S60v5? Fragmentation.

How to avoid fragmentation? Simple: Provide Qt as a "feature" with a quicker release cycle that can be updated every month if need be. Provide Qt updates also for operating systems that don't get updates for the OS anymore. Here's my proposal:

• Provide SSU updates for Maemo 5 for Qt (and Qt Mobility) through official channels (that's the important part here!)
• A new Qt (and Qt Mobility) release should be available on all platforms (Maemo 5, S60v5, Symbian^3, MeeGo) at the same time through official (end-user approved) channels
• Apps targetting stores and repositories (Maemo Extras, Ovi Store, MeeGo Apps/Downloads) should be able to depend on the latest Qt (and Qt Mobility) version

Without that, you'll get fragmentation similar to Android: The 1.5, 1.6, 2.1 versions are similar to Qt 4.6, Qt 4.7.0 and Qt 4.7.1 (for example). Again, you don't need to update the OS, just update the framework - through official channels!

Maemo 5 app UIs: {The,A} big picture

Sooner or later it will be necessary to create a QML UI for gPodder if it is to integrate nicely with devices on which Qt is the "native" toolkit for third party apps. At the moment, the reusable UI elements that can be used with QML (Qt Components) have not yet been officially released (the Git repository is available on Gitorious, though), and there are no UI style guidelines for Harmattan out (yet?). I'm also not able to locate UI style guidelines for QML apps on Symbian^3, and there are only a few small sample QML apps out right now.

Let's look at what we have on Maemo 5 right now. Here's a simplified overview of the current Maemo 5 UI of gPodder:

You can also check out the full-size image (~ 3.5 MB).

The UI follows the Maemo 5 Style Guide where it makes sense and tries to come up with better solutions where the Style Guide does not have a definitive answer. I'd like to hear your opinion about the current UX of gPodder and how these concepts can be translated into a QML app that integrates nicely with "future" UIs (Harmattan, S^3). The new-style episode list that can be seen in this picture will be made available with the next release that will be out Really Soon Now™.

headphoned 1.9 for the N900 is now in Extras-Testing

The beloved Headphone Daemon, who usually sleeps in the darker corners of your N900 and makes sure that you do not embarrass yourself in front of other passengers or pedestrians with whatever kind of experimental music you happen to listen to when the headphones are accidentally unplugged (also known as public transport situations) got a small facelift (also known as code change).

A few changes that have accumulated over the last few months have now been packed up into the shiny new 1.9 release:

• Support for libplayback / whitelisting (by Faheem Pervez)
• Support for pausing Martin Grimme's MediaBox
• Detect headphoned disconnect during active calls and send pause command after the hangup

The last one in this list might be of special interest to some of you who have complained about headphoned not working when the headphones are unplugged during a call. This won't happen now, as headphoned now monitors the call status via D-Bus and keeps track of active calls. When the headphones are unplugged while a call is active, the pause signal will not only be sent right away, but also a second time when the call gets disconnected. This work for all types of voice calls, and should work for video calls as well (untested).

During the summer holidays, I have had less time to do more development and releases, but things are starting to move slowly again - expect new releases of packages like gPodder and MaePad in the upcoming weeks. I'd also love to port gPodder to Harmattan and add a fancy new MeeGo Touch UI on top of it (in March I said that Maemo 6/MeeGo is for later this year - which might be very soon now), so you can all enjoy your favourite podcatcher with the usual native UI support. Let's hope that the Harmattan SDK and/or Harmattan developer images get released for the N900 soon (and then the Python bindings soon afterwards - the PyMaemo team was very fast in previous release cycles), so the community developers have enough time preparing their apps for the next big release.

For now, please test and enjoy this new headphoned release, and don't forget to vote for and comment on the package once you have verified the new release from Extras-Testing.

SketchyAetch, gPodder/Qt and living in the present

After the very interesting Nokia Mobile Developers Forum in Hagenberg on Friday and Saturday (Petri Niemi did several interesting Qt introductory talks), I decided to play a bit with QGraphicsView again and this time try to come up with an app that actually does something: SketchyAetch!

Having not done much with C++ for several months, the GCC error messages (at least for C++) are still kind of cryptic. The fact that code gets pre-processed by moc does not help here, as the error messages might appear in a different location than where the real error/typo is. It should not be too difficult to get around these issues after some practice, and from that point on, getting things done (in C++) with the Qt libraries should be nice.

Already-drawn lines will fade away when you shake your device just like you would expect. The package is available in Extras-Devel.

Now something for the Qt fanboys out there: If you're running gPodder 2.3 on your device, you can try

   python -m gpodder.qtui

for a PoC "yes we could use Qt for the UI layer". This is not something that we will be working on in the near future (after all, the Hildon-based Maemo 5 UI is perfectly fine and "native" and it will get some more fine-tuning with the next release), but it shows that it won't be too difficult to do a DirectUI GUI for gPodder on top of the existing podcast client for M6/MG. We probably get around to implementing a DirectUI GUI for gPodder later this year when it's time to think about "Maemo 6" support.

Looking back how strange the gPodder Fremantle UI looked back in June 2009 (and how much changed in both the Framework and gPodder until the first Fremantle version was released), there's no rush in switching to Qt or DirectUI (at least for existing applications). I just hope that good Python bindings will be available for DirectUI/Qt when it's time to support the new UI, but I'm sure the PyMaemo team will do a great job just as they did with Hildon/Fremantle.

Maemo 5 is very polished these days, and I expect it to be even more mature when PR1.2 is out. It's also nice to see the Qt bits fall in place, DirectUI widget demos being made available, and MADDE becoming integrated with QtCreator, so the tooling support is ready when it's time to write M6/MeeGo apps. Maemo 6/MeeGo is for later this year, now it's time to enjoy Maemo 5, the N900 and all the great open source apps :)