Fighting The Curse Of Plenty: Nokia's Qt SDK

One of the key differences between mobile and desktop development (apart from the obvious GUI stuff) is that applications cover different use cases from their desktop counterparts. How does this difference in application focus and required tool complexity reflect on open, modern, Linux based mobile platforms, and how does Nokia's newly announced Qt SDK address this ?

Android and WebOS took the top-down approach, and made a streamlined development process heavily based on existing technologies (the Java language in the case of Android and web related tech in WebOS). This allowed for fast application development, leveraging existing developer resources and knowledge for the particular platforms, at the expense of making the jump to native code a bit more difficult or the realm of hackers. The very important lesson here was also that they very successfully hid their Linux roots, not making the Linux heritage a drawback (to the point that very few people will actually regard Android as a Linux mobile platform).

However, there was another camp, the bottom-up one, with Maemo/MeeGo and LiMo as the more prominent representatives, which promised most of the desktop technologies in a mobile environment. The advantage should have been the obvious 'just apply whatever technology you know', but in reality, this has slightly backfired up until now. While they proved to be a great basis to hack on and immediately took the hearts of many Linux diehards, there was a steep learning curve that was unappealing to many developers with little Linux background. For example, Maemo's Scratchbox environment and lack of a traditional IDE/SDK are cited being the points where many hobbyist devs gave up on these platforms. In retrospect, these factors sentenced this group of platforms to be seen in the eyes of mainstream end-users as a land of ports and emulators, with the occasional community gem application in the sea of working-but-not-quite-there-yet apps.

Returning to the title - how does this Nokia Qt SDK change any of this, especially with regard to the latter group ? The key is to understand that this is not a classic platform SDK. Let's see what exactly is happening here:

• While the technologies present in the package (Qt, Qt Creator and the cross-compiling tools) are not new by a long shot, this is the first time they start to appear as a cohesive, focused way of creating applications A-Z style.
• A classic IDE-style approach is employed that will appeal to many devs used to such tools, while keeping the power of console and functionality of other existing custom tools.
• It's a toolkit SDK, not a platform SDK. This in turn allows access to the vast array of various platforms and devices. Currently the focus is obviously on Nokia's Symbian and Maemo platforms, but here's where Qt really shines - you're not learning to code Symbian or code Android stuff. The Qt skills you learn are actually just as applicable to the desktop, whether that be Windows, Linux or Mac.
• Multiplatform authoring tools. Currently Windows and Linux, but my guess is that a Mac version could be produced fairly quickly if serious interest appears.
• While Qt provides a level of abstraction, the underpinning platform is not being crippled, and thus applications are being able to take full advantage of it.

As you can see, the goal seems to be to provide a streamlined way of producing modern applications for a range of platforms, while avoiding the dumbing down of platforms to make them fit into a particular mold. I hear you say, okay, so you think this Qt SDK thing will take over the world, right ? Well, while not excluding the possibility, there are a few obstacles that the Qt SDK needs to address before going for world domination in the mobile app development arena:

• Unified (declarative) UI. Cool compilers and cool IDEs do not necessarily mean cool apps. It is paramount that a unified API (based in some form on the Declarative UI of Qt4.7) exists for widgets and app UIs. If each app will have to have it's UI rewritten due do Orbit/DUI/vendor specific/desktop widget issues, that will significantly reduce the appeal of Qt and proliferate curse-of-plenty problems.
• Do a final release in a reasonable time-frame. Today we have seen a beta to whet our appetite, but the other tools and platforms have a serious headstart. Winning Symbian folks over is a good start (the inclusion of Qt libs on the new Nokia N8 will kickstart this process nicely), but the real race is to get on the radar of developers currently under heavy influence by Android and the iPhone.
• Go for Android. This topic alone is grounds for another blog post. Technically, it's known to be possible, there is even is a community level Qt for Android port floating around. I will not go in the business/technical reasoning of the dangers/wins of such a move (maybe in another post), but I feel that it needs to be kept at least as an option, an ace up the Qt sleeve if you wish.
• Add python support. The use of Python Qt bindings has a long and successful history. Python is easy, and on modern hardware, a Python and Qt combination is much less a drag than it ever was on embedded platforms, as proven by PyQt and PySide on Maemo. C++ is not everyone's cup of tea, and Python is an excellent complementary language for it, while maintaining a solid Qt based 'upgrade' path should developers need it. Doing this without switching SDKs or IDEs would go a long way of making Qt even more appealing to new developers.

If you want to take this new SDK for a spin, you can do it here.

Operation Qt Shuffle

I know you all like (cough) my long winded and analytical articles, but we'll take a short break from that to allow for a service announcement concerning our busy Qt developers, Maemo 5 and your evergreen favourite update, PR1.2. 

If you're an end user, the short version is - the doors are open for more (and prettier) apps, plus we have a bridge that will make it easy to backport MeeGo apps to Maemo 5. If you're a developer and/or are interested in the gritty details, read on:

[Maemo community council hat]

One of the big changes PR1.2 brought us is official Qt support in the form of Q4.6 in the Nokia SDK and repositories. This change affects all applications depending on Qt currently in extras-devel. We had some talks with Qt/Nokia folks about Qt-related repository changes in Maemo 5 (triggered by aforementioned PR1.2 and potentially again later on by updates to Qt or related components). Here is the short summary:

1. remove qt4-maemo5 (4.6) after PR1.2
2. upload Qt 4.7 snapshots as qt4-experimental to extras-devel afterwards
3. as soon as 4.6 QtMobility is released, get those packages to the nokia-apps repository
4. remove 4.6 QtMobility from extras-devel
5. maybe upload new QtMobility packages to extras-devel, but only for qt4-experimental (4.7) and with 'experimental' in the package name
6. maintainers of bindings and extensions to Qt are encouraged to follow the same nomenclature in their package names (i.e. using experimental in the name if depending on qt4-experimental)
7. use a Provides/Replaces/etc libqt4-maemo5 clause in the qt4-experimental packages (Qt4.7 packages should be binary compatible with the current 4.6 ones) so the packages can be deprecated peacefully
8. QML/declarative will be released as part of Qt4.7 (so qt4-experimental only, no 4.6.2/PR1.2 support)

[/Maemo community council hat]

What does this mean in plain English ? The libqt4-maemo5-* package names are deprecated in extras-devel. Use libqt4-experimental-* if you need Qt4.7 features, or libqt4-* if you want Qt4.6. Qt4.5 will no longer be supported after the release of PR1.2

Have a nice day !

 

Busy week in Nokia land

The following week is shaping up to be a very busy one for Nokia. Starting today, there is a (largish) scheduled maintenance in the Ovi Store, nearly two days for publishers and most of Monday for end-users. There were hints of some major spring Ovi improvements in the past months, let's hope this maintenance introduces at least some of the new & improved functions.

The second (even bigger) event will be the first MeeGo code drop (a technical preview release for developers), also known as "Day One", which is scheduled for Wednesday (search for March 31), and also a TSG meeting later that day.

Last, but not least, while not really announced, the Nokia N900 PR1.2 firmware release, probably the most important one so far (as it brings all-important official Qt4.6 compatibility) could easily happen this week. The early access PR1.2 SDK has been released a week ago, and the autobuilders on maemo.org have already been transitioned to PR1.2, so the firmware itself can't be far.

The MeeGo release is certainly the most important of all these events, so prep your hacking skills, you're going to be able to put them to good use in just a few days !

EDIT: As pointed out below, this week will also see the election of the Maemo Community Council, which while not strictly a Nokia activity, still plays an important role in the Maemo world. If you are a Maemo community member and have received a voting token, take a gander at the candidate list and their programs and make sure the candidates who you think are best take the seats!

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'.