Introducing New Port of Qt to

Even if this is my first blog post, some of you may have seen my name before. I have been with Trolltech and Nokia since 1996 (which makes me senior surviving Troll), and I am here to introduce a little research project we are starting up.

As you all know, our motto is "Qt Everywhere", and we would love to see Qt run on all the cool devices that are coming out these days, but the problem is that making a port from scratch is hard work: Qt ports generally contain tens of thousands of lines of code, and require intimate knowledge of Qt internals.

One way to port with less effort is to use Qt for Embedded Linux, which provides functionality for adapting to different graphical devices. Unfortunately, doing this is not always trivial. Today I will talk about something that might make things easier, but first a little historical background information:

Qt for Embedded Linux (or Qt/E for short) has been with us now for about 10 years (the Qt/FB project started around 15 October 1999), and it's still going strong, powering everything from small hand-held devices to large industrial machinery. However, times move on, and we are seeing new types of hardware that are very different from what we envisioned 10 years ago.

While Qt/E still remains amazingly flexible, sometimes it starts to feel like a little too much work to port it to some systems. Qt/E
includes its own Q Windowing System (QWS), and this is not always relevant, especially for systems that already includes window system functionality, or features that make it possible to implement windowing in ways we didn't foresee 10 years ago.

We have been looking at ways to refactor Qt/E so it no longer depends on QWS, but there is a lot of legacy there, and over the years knowledge of QWS has infiltrated large portions of the Qt/E codebase. Getting QWS out of Qt/E was starting to look like a major project.

Then, one day, Rhys came up with the idea of starting from the other direction. How difficult would it be to just stub out all the
platform-specific parts of Qt and get a completely new port to compile? Given that most of the infrastructure is already in place
thanks to the raster paint engine and Alien, it should then be fairly easy to get a single process to show a full-screen window on the framebuffer. After talking it over with Rhys, I was starting to hope that this could help with the QWS problem as well, but of course we needed to try it out to see if it was actually feasible.

Rhys had something compiling in less than a week, and we had pixels on screen the next day.

We then played around with it for a couple of weeks, getting most of the crashes out of the system, as well as adding a few more back-ends that showed that we could support slightly more complex behavior.

Then we had to start concentrating on the upcoming 4.6.0 release for a while. However, word started spreading around, and people from all over were asking questions and found out that this could be the perfect thing for their pet project. Therefore, we realized that it's about time to show off the results of our little feasibility study.

The most important thing for a project is of course a code name, and we decided on Lighthouse [not to be confused with a very early preview of Qt for S60 that was used by about 5 people outside Nokia...] since this meant we didn't have to change the Q_WS_LITE platform define.

And of course, the obligatory screenshot. This one's made using the "testlite" back-end:


Boring, right? It looks just like Qt... The point about Lighthouse is how easy it is to write a backend for new hardware. A more interesting picture would be to see how much code is needed to do that. Let's look at the "minimal" backend, which is a complete example showing how to use a QImage as a display device:

~/git/qt-lighthouse/src/plugins/graphicssystems/minimal$ wc -l *
71 main.cpp
70 qgraphicssystem_minimal.cpp
85 qgraphicssystem_minimal.h
101 qwindowsurface_minimal.cpp
73 qwindowsurface_minimal.h
410 total

410 lines of code is not too bad, but, wait a minute! That includes 40 lines of copyright header per file. Sloccount gives us a better impression:

Total Physical Source Lines of Code (SLOC) = 147

Now for something with a bit more meat to it: The OpenVG back-end clocks in at a SLOCcount of 288 lines, and it took about a day to write.

This is still early days, and very little is set in stone (or even properly documented), but you can check out the code, and see some very basic getting-started documentation at:

Just to make it very clear: this is a research project that is just starting out. Don't assume that anything will work, or that any APIs
will stay the same for long. Count yourself lucky if it does not crash horribly and lock up your machine, or worse.

If you want to join in the fun, we can use the mailing list for development
discussions. I also hang around on #qt-labs as paulot from time to time.

Blog Topics: