Introducing Poettering scale of software awesomeness and using

I would like to quickly introduce the Poettering scale of software awesomeness. The scale appears to be number of features over time, the higher the number the better. Evidence has shown that this scale is the best to compare software and should be used whenever one needs to decide on competing projects.

Now that we learned how easily one can find the better piece of software, let's apply it. First Emacs vs. vim. Both are more or less the same age, this allows us to find out if vim or Emacs is better solely by looking at the features. As Emacs can send email, has a tons of lisp scripts it is clearly more "Poettering awesome" than vi. The second example is KDE and GNOME, again both are more or less the same age and we only need to compare the amount of features to know which one is better. We do this by looking at the configuration dialogs, KDE has clearly more options than GNOME. So KDE is clearly more "Poettering awesome" than GNOME.

Device profiles in Qt5

OpenGL and Devices

The future of Qt's graphic stack is OpenGL (ES 2.0), but this makes things more complicated in the device space. The library names and low level initialization needed for OpenGL is not standardized. This means that for a given board one needs to link libQtGui to different libraries and one needs to patch the QPA platform plugins to add device specific bits. The GPU vendor might provide DirectFB/eGL integration but one needs to call a special function to bind eGL to DirectFB.

Historic Approach

The historic Qt approach is to keep patches out of tree, custom mkspecs files that need to be copied into Qt before building. I have had two issues with this approach:

1. Device support should be an essential part of Qt5.
2. Build testing (and later unit testing) is more complicated.

Device Profile Proposal

The approach we took is a pragmatic one, it should be easy for device manufacturers to do the right thing, it should not be a burden for the maintainability of Qt. After some iterations we ended up with device profile proposal and began to implement to it. Most of it is merged by now.

Key Features

It begins with the ./configure script that now has the -device=DEVICE and -device-option KEY=VALUE to select a device and to pass options, e.g. additional include paths, BSP package, to Qt. The second part is a device to influence the behavior of QPA platform plugins. Right now this applies to the DirectFB and EGLFS plugin. A device can install hooks that are called as part of the initialization of these plugins. The hook is the pragmatic approach to get a mix-in with the existing code base.

Supported Devices

Right now we have completed device support for the RaspberryPi,BCM97425 and AMLogic 8726-M. We do support some more devices but they might still require external patches.