Testing QtQuick 2 (Qt 5) on your n9/n950

Published Monday November 21st, 2011
Posted in Embedded, Lighthouse, Maemo, MeeGo, Multimedia, OpenGL, Qt, Qt Quick | Tags: , ,

QtQuick 2 promises superior performance, a new particle system and a host of new possibilities:


It is also quite ripe for testing if you are into that kind of thing. This is my personally recommended approach to testing QtQuick 2 on your n9(50) at this point in time and I have to stress that these steps are not officialy sanctioned. I don’t like chroot environments, and since my builds are restricted to Qt which uses the ever rational qmake build system (lone vocal fanboi here) which respects build (qmake profile) sovereignty, I don’t feel I need one. This is an alternate build approach to the webkit team’s approach linked to below and if you would rather follow in the footsteps of wisdom you might want to tail them.

The Webkit team were gracious enough to jot down these instructions:


which I used to setup the sysroot subsequently employed in my mkspec, available here:


This mkspec clearly has to be adjusted to reflect your local dev paths.

0) Realize this is dangerous and might require the reflashing of your device/loss of user data
1) Install the dependencies (as documented in the webkit teams instructions above) in your HARMATTAN_ARMEL target under scratchbox
2) Replace any fully qualified symlinks under $HARMATTAN_ARMEL/usr/lib with relative ones
4) Run configure directly from qtbase
5) Use the resulting qmake to build the qtdeclarative module
6) Deploy Qt and the required xcb libs to the device (you will need to be root, supplement the existing files don’t override exist files)

You can use:

objdump -x ./plugins/platforms/libxcb.so

to establish what dependencies need to be fulfilled. Up until every required library is present, Qt is gonna tell you that the XCB backend does not exist.

I personally use shadow builds (build out of source) since I am targetting a wide range of devices and discard my builds with fair insane regularity. I have no hit any issues using them in Qt5 when targetting qtbase/qtdeclarative.

Similar steps would clearly probably work for the n900 but, alas, the version of xcb packaged as part of the Fremantle SDK is too old to be used with the XCB QPA backend as it stands. It will take a braver man than me with more time to kill to get that turkey airborne at this point in time. (I also managed to render my Meego 1.2.9 CE unbootable by trying to install the build dependencies, so I don’t see any really convenient avenue for QtQuick 2 experimentation on the n900. Prove me wrong)

Bon appetizer:

Graphic proof of flight, incase you are faring poorly and suspecting that I am a fibber.


The Webkit guys (who tend to have their soup together) have created packages for Qt 5 (along with packing up all the xcb dependencies)



no money back guarantee offered, these packages could quite possibly consume your poodle.

Do you like this? Share it
Print this pageEmail this to someoneShare on LinkedInShare on Google+Share on FacebookTweet about this on Twitter

Posted in Embedded, Lighthouse, Maemo, MeeGo, Multimedia, OpenGL, Qt, Qt Quick | Tags: , ,


DavidB says:

Your blog drew me to the QT 5 documentation. I see QTDeclaritive seems to be a complete rewrite indeed. Question on two Classes listed: QQuickItem and QuickPaintedItem. Why are these classes not merged? When would you use a QQuickItem and not a QQuickPaintItem. Can someone elaborate on these classes.


DavidB says:

So how much does QT 5 break? What is written QML & QML Components version 4 be run in version 5

Donald says:


QuickPaintedItem is a specialized subclass of QQuickItem with enough re(implementation) to warrant reading if you are curious. QQuickPaintItem is what you use for custom painting. Cut and pasted from the class docs:

“The QQuickPaintedItem makes it possible to use the QPainter API with the QML Scene Graph”

Regarding breakage: Qt 5 is a moving target and the world weary should not be straddling it without acknowledging the possibility of being thrown by major changes at this point. That said, I would argue it is ready for early adopters/fiddlers and even QtQuick 1.1 code is proving to run consistently following a sed replace. (Don’t bet your house on it)

J. Hudora says:

Since the article is a few days old, I would be interested if anyone has tested the new QtQuick 2 yet.

sirspudd says:

I tried to get Qt 5 up and running on the n900 (pr 1.3) as well but failed to achieve simple success as the xcb libs available are archaic. (And the xlib QPA plugin appears to be a little GLX preferential. (I didn’t want to waste any time establishing whether EGL functionality (in conjunction with this plugin) is low hanging or not)). A task to the eager reader, looking to get more life out of their n900. (Certainly a larger audience, and one which could stand to profit from the performance/functionality jump)

Commenting closed.

Get started today with Qt Download now