QT/KDE on OpenWrt

As you may know OpenWrt’s collection of ported packages is continuesly growing.

Many graphical stuff gets ported, as well as graphical desktops and toolkits (lxde, xfce, gnome based on GTK2 – e17 based on the enlightenment foundation libraries – etc.).

However there was no approach yet to port the last missing Desktop “KDE” and underlying Toolkit “QT”.

That’s why I went to “Tokamak 4” this weekend, a meeting organized and founded by the KDE foundation, intended to communicate and hack together related to several KDE software projects.

We were about 25 people from all over the world and I really enjoyed the stay and nice, friendly and mixed party – surprisingly I was the only one not using KDE (however not for a special reason – just got used to my current environment) :).

They showed lot’s of interest in the UCI-System (Unified Configuration Interface) OpenWrt is using.
It’s a simple, human-readable, easy-to-parse configuration file format and library OpenWrt uses for services to make it easy writing Administration Interfaces for them (e.g. the webinterface “LuCI”).
We were spinning around about KDE Plasma applets which will list available OpenWrt-devices ready to get administrated right through native applications.

Key deal for me however was to get in touch with people who know the QT/KDE architecture very well, for sure promoting a bit OpenWrt, qi-hardware and it’s concept of open hardware and why I think having QT/KDE support within OpenWrt is opening lot’s of opportunities for both projects.

Since QT is able to use DirectFB (a very powerful but light abstraction for the linux framebuffer) – and therefore does not require a X11 system necessarily – it would be also great for limited hardware such as the Ben NanoNote (32MB of RAM) where I got GTK2-based apps running on top of DirectFB quite some time ago.

I expected to get basic support for QT within OpenWrt done this weekend, however I underestimated the size and complexity of QT – never touched QT-code before.
I realized QT is not just a toolkit as GTK2 is, but a whole framework which tries to abstract as much as possible from the underlying system. It features own backends for multimedia, sound, graphics, even networking – to achieve a stable API and platform compatibility without the need of code modifications, no matter which backends or systems are used below.

In which way the typical issues of such a abstraction-concept – such as getting bloated, having performance issues, being feature-limited as you’re usually just able to support the least common denominator of all supported backends, etc. – I’ve no idea yet – maybe they found a way, will find that out sooner or later.

They also use “qmake” as build-system which is structured quite different than e.g. GNU make, so this got another temporary road blocker as I used qmake never before and had to dig in first.

Back to the port of QT to OpenWrt: I’m having promise to see the first basic QT based application running on a OpenWrt supported device within the next days.

Will let you know