Is that empty chair yours? Credit: Fleury.

The Qt team started September with a Mega Release Day topped by a bunch of fresh information about Qt Developer Days, the main and dual headed event of the Qt community. I looked at the calendar and realized that I’m starting to be late on planning if I want to make it to Munich on October 24-26. I still don’t know about the European gathering, but I’m logically planning to be in the San Francisco event on Nov 29 – Dec 1.

Qt Dev Days is a good opportunity not only to learn and get to know about the latest technical progresses and plans: it is a chance to meet a wide variety of people face to face, discuss and exchange extensively. This is an element common to any good conference, but especially in the context of the Qt project here and now this aspect is essential. Qt has been in the eyes of many in the past 12 months, but too frequently simplified and polarized to levels that go far away from the reality of the Qt project and community today. I frequently refer to Qt as a jewel in the Linux and open source software stack. A very versatile and precious piece able to play with many different products, projects and organizations. Qt Dev Days shows this in a way no blog post or analyst insight can reflect.

I’m glad to see Intel, Canonical and Telecomm Italia in the keynotes, as well as other companies like Cisco or Panasonic Aviation in the Qt In Use sessions and the many sponsors taking the floor. The Qt project has many different stakeholders, and hearing about them helps enriching the perspective that (lately) is circulating almost obsessively around Nokia and handsets only. Of course Nokia and handsets are important for the Qt project, you will have a chance to see and grasp the latest Qt based products from Nokia and there are many sessions scheduled in the Technical Track covering that and more e.g. Qt in MeeGo, Symbian and Android. There are other sessions exploring the new areas such as Qt Quick in the desktop, training and tools specific for designers or te WebKit / HTML5 neighborhood.

Even if Qt Developer Days has been an event primarily professional, the trend has been to open the doors to the increasing interest and innovation coming from developers with not-for-profit motivations. If you are one of these, you have a way to make it to Munich / San Francisco and you have an objective way to show your Qt love and dedication, please poke me here or through my address (easy to guess). We’ll do our best getting you to the event at a discounted price. Sorry, I can’t give more details now since I just poked the event organizers myself asking for details. In this context faster is better, just post/send a couple of lines with link(s) to your project(s).

A month ago I downloaded the last Qt SDK, plugged my Nokia N9 to it and started writing from scratch a chess game UI. This week Miniature 0.3 Berlin Defence has been released sporting a demo UX running with real Qt Quick code of my own forge. I have learned a lot with the help of many and I can’t describe how happy I am now – even if this is only the beginning!

// Skippable background

This was my debut at programming, preceded only by HTML web pages in 1995-97 and a Basic sketchy game with 3 sprites that never went beyond the Commodore 64 we had at home around 1983. In fact as a teenager my vocation was always split between natural and artificial languages, and only after a close tie I started my studies in Communication Sciences – Journalism branch. Since then I’ve written a lot and I’ve learned to describe, specify and instruct by putting words one after another (still not as good in English as I would wish).

For what is worth I’m not a designer either. At the university I devoured the splendid collection of comic books of my faculty but I didn’t succeed at drawing my own strips. Still, I had the luxury of living surrounded by creative, practical and pragmatical people with a varied range of skills and tastes. Over the years I have developed some sense of how new things could look like and behave. Conscious of the big amount of time it takes me to use Gimps, Adobes and the likes only to come up with mediocre results, most of the times I resort to concepts on paper.

But let’s go back to the chess program.

// Skippable background about the chess program

Two years ago I had convinced the great Michael Hasselman (mikhas) and a few others to create the Miniature project, being my main tools of persuasion a plan on a wiki page plus a pencil draft. Not being a programmer or a designer, these are the weak arguments you have at reach to get things done. Miniature had a short and unstable life in the Maemo extras-devel repository for adventurous N900 users. You could say we didn’t succeed… yet some of my best moments with the N900 (and I had many) had Miniature running in the foreground. For instance, playing late night with the also great Iván Frade in Meritähti, the cozy and nutritious bar no tourist guide will recommend if you ever visit Helsinki.

After the N9 launch I saw with despair that proper mobile chess was still absent in the Qt catalog. I made a second call, and almost miraculously mikhas answered again, but this time stating clearly that he would focus on the backend and somebody else would need to work on the UI. I looked around. I looked myself in front of the mirror (mentally, I mean). The first Miniature had to deal with Qt 4.6 and QGraphicsView with no cutton or oil. Hardcore stuff. Now the declarative and Javascript friendly Qt Quick was at the forefront, waiving the slogan of Programmers and Designers Unite! I decided to give it a try, getting a tacit permission from my manager to call some of this time “training”.

And yes, this is great training! Sitting in front of tutorials and code examples for the sole purpose of learning is boring – at least for me. Trying out things, copypasting code from somewhere, asking on IRC and forums, building and rebuilding until the damn thing works is überexciting – at least for me.

// Finally some actual stuff

These are some pros and cons found during the first stages of this trip. I hope they are useful for others like me, getting started in Qt Quick and in programming. They are all mixed since frequently a con leads to a pro and vice versa. In some cases it’s not even clear whether the thing is a pro or con, but it’s remarkable anyway:

The Qt SDK is such a beast
And I got my way with relative ease. Accessing documentation while writing code, connecting to the device… The first time I couldn’t believe my dummy rectangle was showing up in the N9, an icon was added to the app grid and a .deb package was sitting in a local folder of my laptop.

But Qt Designer can’t be used yet
I had so much hope in Qt Designer for my first steps. I had played with it and it reminded me the old good Macromedia Fireworks, with the additional advantage of generating actual code. Then I found out that it was basically of no use here and now for MeeGo development.

Neither the Simulator, and even the emulator…
Qt Simulator didn’t digest MeeGo either, here and now. QEMU could but… Good that I had a device because the simu/emu would have required a lot more time for someone new like me, needing to see how things progress every 2 new lines.

Getting started with Qt Quick is really simple
Without Designer I quickly realized that typing directly the code in a proper SDK was simple enough and probably lead me to cleaner and more solid structures. I started to learn how QML thinks, and starting to guess what would and would not work even before pressing the build & deploy button.

The documentation is extensive, but still not consolidated
QML and Qt Quick have evolved a lot in a short amount of time, and different audiences with different background are meeting there almost for the first time together. All in all it feels that whatever is different from Qt/C++ is explained in detail (e.g. anchors or pure UI elements) while other parts closer to traditional Qt are mentioned with more brevity. This is surely fine for Qt/C++ developers, but this is also where the less experienced or more web oriented developers might get stuck. In some points I have missed more basic descriptions, wider code examples… oh, and many more screenshots showing how demo apps and components are supposed to look like without having to run them in the SDK.

The community is savvy and very helpful
Whenever you get stuck in something you start looking for help. I didn’t rely (much) on the professional developers sitting few steps away from my desk (except for really embarrassing basic questions). I put my immediate hopes in IRC, but being August and typing from PST got me more silence than expected in #qt-qml. Still I got some great answers from e.g. special and frals. #harmattan was a second resource but the Scratchbox – Python – middleware angle of that group is noticeable. #miniature is obviously useful but I didn’t want to exhaust the patience of mikhas… Then I decided to become a Lab Rat (now a Ant Farmer) in the Qt Developer Network and since then the forum hasn’t disappointed me once. Getting the attention of a troll, a certified specialist or just the right person with the same (solved) problem is just a luxury.

The veterans don’t have always the right advice for you
These days I’ve got many Qt answers to my QML questions… since I was asking to Qt savvy developers. That helped me understanding better my own questions, and finding out where to find the QML centric answers. Like for instance “how to put a link to a web page opened by the device browser?”. Sure, Qt and DBus can do wonders for you – but actually the right answer for me was something a lot simpler: Qt.openUrlExternally(). The feeling was familiar: years ago GNOME desktop developers would answer my questions with “open terminal and type…” when actually the desktop itself offered solutions not involving a console.

Backend and UI can really be developed in parallel
While mikhas has been working hard on a C/C++ backend containing abstract models, internal logics, capacity to talk to the Free Internet Chess Server via telnet and to plug into GNU Chess, I was able to define a UI with all its interactions almost autonomously. I actually started with an own QML project separate from Miniature, until mikhas liked what he saw and decided to integrate it. I just had to leave comments in the code: // FIXME this is a static string, the backend should hook here with a real variable. Now we are basically at the point where mikhas has a backend that play games you can’t see, while I got a nice UX that doesn’t know any chess. Sewing is happening as we speak.

Open source development is just great
If I started with Qt Quick from scratch one morning, on the afternoon I was already learning how to get that code and package out of my system, to be seen and tried by others. I didn’t get much attention at the beginning, but only the fact of writing publicly brought me to structure things as good as I could (still crappy, I know) and to comment a lot more and better that I would comment just for myself. Again the Qt SDK was useful here, generating packages that install and bridging with git nicely. Additional thanks go to the maintainers of and to the various authors of little but useful code snippets borrowed here and there. Every time I said “I can’t be the first one having to do XYZ” turned out to be true. Someone had gone through that and was sharing the result with the World. Thank you, thank you very much.

// This is getting longer than expected. Again.

I feel a lot better, even if these days I’m suffering a lot more. 😉 Playing with ListModel, GridView, states and animations hasn’t been always funny but after many trials and errors I got exactly the behavior and the effects I was looking for. Now a new Miniature contributor can come willing to implement the logics for e.g. chess by email and I know I will be able to help providing a decent UX. In the meantime Qt5 and myself are getting closer to deeper Javascript support, which looks promising and a sure continuation of the fun!

I’m about to start my second month of Qt Quick programming. Miniature 0.4, here we go!

MeeGo 1.2 Harmattan

[Disclaimer: The opinions expressed here are mine.]

There has been a lot of discussion about MeeGo and its future, now reinforced with the launch of the Nokia N9 – a great product that seems to leave nobody indifferent. Here you have some thoughts cooked between #feb11 and tonight (even if Helsinki has little night to offer to mid-Summer visitors).

One problem in this discussion is that a lot of focus is being put in the word “MeeGo” when actually it’s a label that can mean different things to different audiences in different contexts. In fact though, the label doesn’t count as much as the actual software underneath and the projects involved in its development.

The Nokia N9 is powered by MeeGo 1.2 Harmattan, the OS equipped with this UX that has impressed to many. Now, let’s have a look under the hood to see what parts of it really matter to the MeeGo project, the OSS community, the developers and users interested in the N9:

Linux Kernel

We are talking about the mainline Kernel. Needless to say this project will continue to live and evolve. Nokia may keep contributing to this project and using it for R&D and future products – nothing announced at this point beyond this reference of ‘MeeGo’ in relation to the ‘future disruptions’ strategy.


This is another rich label meaning the toolkit, API, SDK, a variety of technologies involved… The project is in good shape with a promising future based on Qt Quick, the innovations and open governance model being implemented for Qt5 as we speak. The Nokia N9 is a Qt champion product, there are 100 million Qt-enabled Symbian devices (a lot more are expected) and Nokia just announced that Qt will have a central role in its ‘next billion’ strategy. Beyond Nokia, Qt also continues its growth.


Another key OSS project where Nokia is a veteran contributor. Plays a key role connected to the increasing relevance of HTML5 (yet another vague label) in the mobile industry. Both WebKit upstream and the team(s) working on it at Nokia have a bright and busy future.

swipe UX

It doesn’t even aim to become a label, but has captivated already the attention of many when seen in action in the Nokia N9. As a happy user and earliest tester I’m proud of what we have achieved.  Stephen Elop has said that it will live forward and evolve in future Nokia products.

In my opinion that’s it. This is what really matters about MeeGo 1.2 Harmattan when it comes to discuss about future products, platforms and ecosystems. Note that these four pieces are very versatile and flexible, they can play with each other and they can also head towards other paths, offering many possibilities for future products.

The rest of technologies involved in MeeGo 1.2 Harmattan are also crucial in terms of functionality and success of a product, but they are more the sort of interchangeable glue, technology in motion that may change because of life cycles, hardware, providers, technology selections, etc. The projects and companies developing the myriad of pieces know this well and work hard & fast to either push new releases or jump wagon to whatever is the new future greatness.

Now, it turns that the rest is very important today for the MeeGo project when it comes to define what is a MeeGo compliant product. According to this definition, if you miss the rest then you don’t have a MeeGo product, unless you propose and obtain a trademark exception.

(((Another approach would be to simply define MeeGo = Kernel mainline + Qt + WebKit, syncing app developers around the OpenGL, Qt and Web APIs – but this is not the reality today)))

With all this background in mind, you can put a vague question in more precise terms:

– If the Nokia N9 is successful will you ship more high-end smartphones powered either by MeeGo 1.2 Harmattan or a fully compliant MeeGo?

Since #feb11 Nokia has a clear software strategy where high-end smartphones are covered by the collaboration with Microsoft on Windows Phone, therefore the consequent answer is the one already given by Stephen Elop: No.

However, look back at the four essential pieces above and keep in mind that Nokia is investing in all of them. Even if working on them is really fun, you may guess that Nokia is not paying the teams for the fun of it. It is sensible to expect more to come in a form or another.

Considering that Linux Kernel and WebKit will continue evolving no matter what Nokia decides and assuming that the swipe UX will continue evolving in Nokia products, in reality the concern about “the future of MeeGo at Nokia” is tied to the future of Qt: Nokia’s investment and leadership, involvement of other parties in a wide community, usefulness addressing the mobile and cross-platform challenges, increase of the developer base, increase of the quantity and quality of Qt apps… There is a direct correlation between the success of the Qt project and the satisfaction of the future N9 users, even if most of them won’t know ever.  🙂

Qt was relevant before Nokia acquired Trolltech. Nowadays is more relevant than ever, and is evolving fast. It’s a great piece of open source technology that can compete side by side with the leading toolkits. I only expect a bright future for it, sitting between the Linux stack and WebKit, powered by its championing capacity to support multiple platforms and enable multiple UXs.

For all these reasons I’m really happy about the arrival of the Nokia N9 and its role in this interesting chess game. About the future, since I joined the mobile industry in 2007 only one true has prevailed: no matter what your prediction is, the reality in 12 months will be different and unexpected today. Enjoy!