Qt Components - The story of the ugly QWidgetling

Disclaimer: these are my own, personal thoughts, not necessarily matching those of my employer, neighbor, goldfish or innocent bystanders.

Paradigm shifts are always difficult, especially when linked to technology changes. Qt Components are here and seeing that there and at least three component sets (MeeGo Harmattan, Symbian, MeeGo UX) and counting, it is hard to see how components will help solve the cross-platform problem that has been plaguing mobile developers. Hard to see, if you think about Components as a QWidgetling, that is. In the vein of the story of the ugly duckling, I will try to explain how you can utilize Components and avoid the feeling of being given a square peg when you are looking at a round hole. To repeat, this is about figuring about just what QML with Components is, how it's supposed to be used. Disclaimer #2: Those who think QWidgets should have been the long term technology of choice, or hate QML with a passion, please skip this article. You're not going to like it, and I'm usually delete-button-happy, so save the angst and skip it. Sorry and thanks.

QWidgets

If I was trolling, I would say they were (mobile-wise) the cross-platform solution that never existed - it certainly *sounded* good that I, as a developer, work against an API and the UI framework works out everything, resolution, input method, hardware be damned. This, however, is a bit like listening to politicians - just vote for me and I will solve all problems. Well, not quite. As many have outlined, the paradigm shift from the "I wrap everything to native controls which
 kinda look/work the same" characteristic for the desktop spelt doom for the classic widget based approach. I have gotten nasty looks IRL for saying this, but Maemo5 did not prove QWidgets is the solution - it proved that it is NOT (yes, I be trollin', but only to make a point :). It was a great effort, and while the looks were certainly on par, your supposedly cross-platform code was a mess, full of #ifdefs, modules and classes specific to Maemo5. As I sometimes say, well, with enough ifdefs, you could switch between GTK and Qt, right ? At the same time, development was not made any easier - there were no specific UI tools for creating Maemo interfaces.

QML, and the long road to Components

Enter QML, a radically different approach. As people soon realized, QML is a base technology, it does not provide you with buttons or much higher level functionality you previously had with QWidgets. Also, at the same time, it was said Qt Components will solve this. All was well, it was just a little wait and we will have our new incarnation of QWidgets, right ? Well, not quite...
 
QtComponents have hatched...

... and it turns out they harbor a pretty ugly QWidgets replacement. People trying to make QML that runs equally well on Harmattan using the Harmattan components, Symbian using Symbian components already felt this is not good. Recently I got a contribution for QtInfo in the form of a cool Symbian components UI. I tried to kick it around a bit to make it work on Harmattan, with bleak results, with projects diverging already at the HelloWorld. Something was wrong. This duckling was really ugly. After a few days, however, it dawned on me...

A chainsaw cuts trees faster than an axe only if it's on

The reason I was suffering and losing time was because for years I have been taught to think (much in the vein of QWidgets) almost axiomatically that I want a single codebase and with enough tweaking (ifdefs) it would run equally well on platforms. That is no longer necessarily true (if you think I'm losing my mind, that's understandable, but read on). In terms of the title of this paragraph, I had Components (the chainsaw) and I was hitting the tree with it like I would with an axe, and it really is a horrible experience. However, there is a paradigm shift on the horizon. Turns out, Components solves the cross-platform challenge NOT by providing a singular API. It attacks the problem by making is super-easy to write throwaway code. WHAT ? (if you think I *completely* lost my mind, that's understandable, too, but read on).

Live fast, die young

One of the key appeals of the old widget approach was their enduring nature. If you wrote a desktop application 10 years ago with it, it would likely work okay today. However, this age of UI tranquility, taken for granted for so long, is in it's final days. As we've seen, today even the most conservative desktop OSs are undergoing UI paradigm shifts. Mobile is even faster, 4 years in mobile is an eternity. Writing an UI as if it was there to stay for decades is losing appeal quickly - the life expectancy of mobile UIs is dramatically shorter, which coincidentally also lowers the long-term maintenance burden, traditionally so important to developers.

Use the Force. Let go, Luke.

As Ben Kenobi said. And even though it seemed weird to the people in the rebel base for Luke Skywalker to use the Force instead of the targeting computer, it shows us what's happening here. Let go of the idea of monolithic, single UI codebases. Let. Go. Like the huge armor of European medieval knights on appearance of the guns - the armor no longer provided real protection, but made you slow and unmaneuverable. So, what should I do, I hear you asking ? EMBRACE DIVERSITY. Use the weapon/components best suited for the platform. Don't be afraid to improvise or include your own Elements, or borrow (barring license limitations) from Components of other platforms. Keep your UI (QML) layer as thin and nimble as possible, keep the logic on the C++ side, it will help you both in terms of portability and speed. Spawn as many UIs as you wish. Think about the UI as a throwaway component. Is it Harmattan ? Okay, I'll just drop in the QML from the examples, who cares if it runs on Symbian. Different resolution ? I'll just include a different QML optimized for that. I can see the disbelief in your eyes. How can this work ? The point is that spawning UIs with QML is *fast*. Really fast. Actually way, way, way faster than tweaking for a certain subset/common API or resolution independence. You will write (and maintain !) 5 different UIs *faster* than you would write a monolithic QWidgets UI that would work truly cross-platform. It is a radically different setup. Returning to my QtInfo porting example - it took me nearly a day to create a port from the Symbian-only version to a version that ran on both Harmattan and Symbian, but it meant a lot of compromises and visual artifacts, rotation and integration issues. However, when I realized the new paradigm I outlined above, I had a sexy Harmattan fully integrated native UI up and running in 30 minutes, just appended the QML to the package and now the application is cool on Symbian, Maemo, Harmattan, the Desktop, and I could add a tablet MeeGo UX in another 30 minutes.

There you go, with all the acknowledgement that this might be hard to swallow for many of you, trusty old QWidget veterans, hopefully I now explained just what kind of square peg Qt Components I see and you will hopefully stop trying to shove it in that round hole :) Now go and make Qt Components shine and create beautiful swans of Harmattan, Symbian, MeeGo, or whichever platform the Qt winds might blow on.

Harmattan: Last of the Maemos or First of the MeeGos ?

It has been over a month now that MeeGo, Nokia's and Intel's joint mobile linux effort has been announced. The original formula was for Maemo 6 (also known as Harmattan) and Moblin 2.2 to merge, and form a Maemo 1.0 in the next iteration. This was cool and was generally well accepted (except for a few not too well communicated points like switching from Maemo's DEB to Moblin's RPM). Let's delve into the branding/community aspect of Harmattan, the upcoming protoMeego!

The Maemo 6 device is not even out yet, only announced for the second half of 2010. So, how does one prevent the Osborne effect? Well, the immediate, and understandable reaction was dropping the Maemo 6 brand for Harmattan. This seemed a bit of a middle ground, but it is evident that most people have never heard about Harmattan and will have trouble placing it in the correct position with regard to Maemo and MeeGo, so later  a MeeGo / Harmattan name started appearing. In interviews and blogs, even top Nokia folks regarded Harmattan as MeeGo compatible, or an instance of MeeGo. In theory, if a device implements the MeeGo API, it is MeeGo device, if it doesn't, well, then it isn't. What does this mean in practice? Hard to tell, unfortunately. The first problem is that the MeeGo API itself has not yet been publicly released, only outlined in a very rough architectural sketch. Furthermore, as discussed in my previous article, this Harmattan / MeeGo is not the MeeGo the N900 users (think they) will be getting. Many of you will say, why does it matter? If the SDK helps overcoming the RPM/DEB divide, isn't it pointless to point out "differences is obscure middleware components"? Well, sadly, the question is a lot more complex than that.

Arguably one of the biggest differentiators and unique aspects of the Maemo platfom is/was the well organized community at maemo.org. Many of you unfamiliar with the inner workings might think it's just a forum or a download portal of some sort, but in reality, it's almost a country of it's own. It encompasses several communication media, from forums through blogs to mailing lists, documentation and the complete community development and distribution process (which accounts for 95% of available software for Maemo devices). Another way this little country is unique is that is has elected representatives, and encompasses all sorts of users, from casual surfers through power users to hardcore developers - something very few communities of this size manage to do. This makes maemo.org and everything it stands for an invaluable asset of the Maemo platform. What does this mean with regard to Harmattan?

I hope the problem is starting to become apparent - by pushing Harmattan users into the meego.com fold, they will miss out the experience and momentum maemo.org has. At the same time, there will be a realization that the only thing in common with their Intel, LG, etc 'neighbours' at meego.com is the name itself - they will be using a different package format, different repositories, different DRM, different architecture, different (but similar) APIs, different application store and IMO it won't be long before it will be perceived as a MeeGo stepchild and the Harmattan section will be littered with 'when will the Harmattan device get a real MeeGo?' or 'why does everything have to work differently on Harmattan?' threads.

Okay, I hear you say, then they just integrate it with maemo.org and let it live through it's protoMeeGo days along with it's N8x0 and N900 predecessors until it really gets to be MeeGo 1.0. Unfortunately, that's not a decision without drawbacks, either. Right off the bat, there is the marketing problem of this making saying it somehow 'old', obsolete. In reality, it's not Harmattan that is obsolete, I feel that it was the MeeGo announcement that was in many ways premature as it is really something that affects the 2011 time frame of devices, anything before that will be MeeGo in name, not essence. And this brings us to the second problem of this approach - if the community coming with the Harmattan device is part of the Maemo community, there will be no substantial (read: one including end-users) Nokia device community present on meego.com until well into 2011 and the first 'designed for MeeGo' devices.

What's the solution, then? Harmattan is in a tough spot, Nokia aiming for high and noble long term goals, but that does not ease necessary near-term choices (especially considering they already made the most important one - going forward with Harmattan as planned regardless of MeeGo). I already talked about the branding problems - this is something only Nokia can decide on. On the platform side, I feel the maemo.org community can help, but solid bridges need to be built between maemo.org and meego.com, to allow for users to harness present-day community resources and experience, at the same time allowing them to grow/migrate into meego.com when the time is right. Trying to push them into a future meego.com infrastructure now could easily hurt Harmattan (and indirectly Nokia's own long term MeeGo) efforts.

DISCLAIMER: A lot of things about MeeGo are in flux, things becoming more clear when the first Harmattan and MeeGo SDKs are released (this should happen in just a few weeks).  I'm pretty certain there will be updates based on those coming for my little analysis above, so let's see what the future (and various MeeGo stakeholders) hold !

The danger of weak branding or: which MeeGo is the real MeeGo?

By following various blogs and forums, it occured to me there is quite a confusion as to what actually MeeGo is. The basic idea, announced in Barcelona during the MWC, was to have Maemo and Moblin merged into a new OS called MeeGo. So far so good (number of MeeGos: 1). However, recently Nokia re-branded Maemo 6 as MeeGo / Harmattan, which uses a different package format, repositories, so not quite the same MeeGo that was originally announced, despite the general similarity (number of MeeGos: 2). In the same vein, Moblin folks started calling Moblin 2.2 simply MeeGo (number of MeeGos: 3). But wait, the plot thickens! It has recently been confirmed that the N900 will be Nokia's reference platform for ARM-based MeeGo devices. Now, this is closest to the MWC MeeGo, but is just a developer reference platform, not something that end users are expected to install/use (number of MeeGoos: 4). Getting dizzy? Take a look at meego.com, you'll see that MeeGo also intends to provide separate versions (as in different user experience) of  MeeGo not just for Pocketables. There will be distinct editions for Netbooks, Media Phones, TVs, In-vehicle devices and, as you probably guessed it by now, they're all called MeeGo (number of MeeGoos: 5, 6, 7, 8). So the next time somebody asks for or talks about MeeGo, make sure it is clear what the object of the talk is, lest the discussion turn into Marklar.

This problem has been usually tackled by subbranding, for example Ubuntu very successfully uses names like KUbuntu, XUbuntu, Edubuntu, Ubuntu Netbook Remix, etc. Why is this so important you ask? MeeGo targets a very wide range of devices and users, far more diverse than Ubuntu. By allowing everything to be called MeeGo, despite having different UIs, architectures, application stores, DRMs, APIs, packaging systems and repositories, MeeGo becomes a weak brand. It will no longer be important whether something is MeeGo as it provides no guarantee of anything except for a generic Qt based compatibility (which means little to end-users). It's crucial this branding mess gets cleared up by the powers that be before the first releases are made and the first devices hit the streets, otherwise MeeGo (all 8 of them if I counted correctly) risks going from a strong distribution brand for the embedded industry to being just a generic synonym for 'Linux with Qt'.