Author’s Archive: jacob

Home / jacob
27 Posts

You have written your application with Qt and now you are going to deploy it. On MacOSX, you want to use macdeployqt, on Windows you need to copy all needed DLLs next to the executable by hand. And on GNU/Linux? Well, there are two ways: Either you are going to package your Qt app for specific package management systems, there you can make use of the [OpenSUSE build service][1] for example.

The other way is to link as much as possible statically and deploy your app as a huge package within everything ready to run. For this to work, you need to build Qt from scratch statically and link all third party libs in. This tutorial assumes you have your Qt files in “/opt/Qt”. Within this source directory you will find an application called “MaintenanceTool”. Use it to ensure that you have installed “Source Components” for the version of Qt you want to use.

Create a directory next to Src/

mkdir /opt/Qt/5.4/build && cd /opt/Qt/5.4/build

and run the following command. Note that you need to specify the target directory where the finally built static Qt set should be located. I specified “/opt/Qt/5.4-static”, so have them all in one place on my system.

../Src/configure -static -opensource -release -confirm-license -no-compile-examples -nomake tests -prefix /opt/Qt/5.4-static -qt-zlib -qt-libpng -qt-libjpeg -qt-xcb -qt-xkbcommon -qt-freetype -qt-pcre -qt-harfbuzz -gtkstyle -openssl-linked -largefile

Afterwards, run:

make -j 4

Now this may take a long time. When it is finished, run

sudo make install

Now you should be able to select the static Qt set from within QtCreator and rebuild your app with it. If you want to make sure, all went fine, go to the directory the resulting app is in and run

ldd appname

There should be not dependencies to Qt libraries, libpng, libjpeg, libxcb and so on.

QtPods is now equipped with two more useful features. It now automatically connects to the #qtpods channel on freenode irc directly from within the QtPods app.


Also, the issue tracker is directly integrated:


Some of the coding conventions for QtPods seem to be gratuitous and often I am ending up explaining which ideas led to them. I think it is important to not only document things as they are, but also why decisions have been made. The goal is to help people who are contributing to understand and accept the overall appointment. We have thought and discussed countless hours and often we had to make compromises. Recognizing that there may be people with different, reasonable (and less reasonable) needs is essential. Unification and agreement brings a lot of advantages but does not only mean enforcing your rules on others.


The overall consensus seems to be that pods are called QtFoo officially. Repositories are all lowercase (qtfoo) and do only contain the pod sources, no documentation, tests or examples. Examples go into qtfoo-examples and so on, where qtfoo itself is integrated as a pod. Unless there is a technical limitation, the headers inside are called foo.h (ie. without the prepended “qt”). This is because only official Qt modules are prepended with “Qt”, pods aren’t official Qt modules. Only official Qt classes are prepended with a “Q”, but this also doesn’t apply to us.

There is only one reason we keep the “qt” in the pod and repository name: Pods can always be build outside the scope of QtPods. If they were only available within QtPods, we’d gracefully leave the extra “qt” out. Unfortunately (or fortunately :)), they’re not, so we keep the extra “Qt” to express their affinity to Qt.

File names are all lowercase – thus following the Qt standard. Also, a camel-cased “C++-version” is allowed. These should only be forwarding to the lowercase version. If you take a look at the “QString”-header for instance, it is forwarding to “qstring.h”.

Class names are camel case, e.g.

class VeryNiceClass {

Include order

Own includes first, then third party dependencies, then Qt includes. This makes for a better separation of which class relies on another class within the code.

Build system

The build system is qmake. We thought about integrating cmake, but there are difficulties involved: We would need to drop the support for qmake entirely or hack around to integrating cmake-based projects with qmake. On a second note, cmake would be an extra dependency. Politically, qmake still is the standard build system for Qt projects. Although cmake is supported by QtCreator, it does come with Qt itself. There are numerous other build systems supported by QtCreator, for example GNU Autotools. It is well possible to build Qt apps with Autotools, but we didn’t take it for the same reasons we didn’t take cmake.


We followed the github standard. If you create a new project, github will optionally create those two files, so why fighting against it? If you are incorporating foreign code you will always need to know the license and some information on how to use it, so those two files are being enforced.

Flat directory structure

You can assume that pods and the final application(s) root folders will lie next to each other.

Static libraries vs dynamic libraries

There seems to be a widespread opinion that dynamic libraries are intrinsically better for no sane reason. The truth is, dynamic libraries suffer from many technical problems: You have to keep binary compatibility, dynamic libraries open up a second global variable space (yes, you can have two global variables with exactly the same name and it will compile gracefully, but crash while executing. Using the debugger you will find out that the same symbol may refer to multiple addresses in memory), on some platform versioning can be problematic and there are different, OS-dependend policies on where to find them and which to load. So, after all, you need good reasons to use dynamic libraries. There is no meaningful reason QtPods should use dynamic libraries and by using static libraries we are eliminating so many problems rightaway.

pro- and pri-files

If your project is called qtfoo, QtPods requires exactly two files: which is used to build a static library and a qtfoo.pri that will be included in the final application’s pro-file, so it should contain instructions for the final target: It should set include paths and link to third party libraries libraries. This is how a pro should look like:

CONFIG += staticlib
TARGET = qtjack

    system.cpp \
    buffer.cpp \
    client.cpp \
    driver.cpp \
    parameter.cpp \
    port.cpp \
    server.cpp \
    netslave.cpp \
    netmaster.cpp \
    audioport.cpp \
    midiport.cpp \
    audiobuffer.cpp \

    system.h \
    System \
    Buffer \
    buffer.h \
    Client \
    client.h \
    Driver \
    driver.h \
    Parameter \
    parameter.h \
    Port \
    port.h \
    Server \
    server.h \
    processor.h \
    Processor \
    ringbuffer.h \
    RingBuffer \
    netslave.h \
    NetSlave \
    netmaster.h \
    NetMaster \
    audioport.h \
    AudioPort \
    midiport.h \
    audiobuffer.h \
    midibuffer.h \
    AudioBuffer \
    MidiBuffer \
    global.h \

And this is the corresponding pri. The $$PWD variable contains the directory the file is located in, so this is a convenient way to give a general instruction to add the pods root directory to the include path of the final application. I prefer to keep two separate LIBS statements, one for the pods’ static library and one for third party dependencies, but that’s personal taste.


LIBS += \
    -L../qtjack -lqtjack

LIBS += -ljack -ljackserver -ljacknet

The current office we’re working in at 9e has an annoying hindrance: The door opener is located a couple of steps away from every office, so everytime someone would ring the door someone had to interrupt his work to walk to the door opener. If you do that often enough you’ll be getting inventive.

During our hackathons, some of us took an arduino board and build a simple webserver. Upon each GET request, the door would open. Unfortunately, this was rather a first estimate and couldn’t be used productively. The poor man’s version of this was an ethernet controlled plugboard. I just sticked an USB charger into one of the sockets and connected the +5V to the relay. Now we were able to at least open the door via the plugboard webinterface.

We later refined that arduino idea: In a second try, we took a thin client and wrote a rails application that would just use the arduino as an I/O interface to trigger the relays that simulated pushing the door opener button. Clients would communicate via web sockets now.

Unfortunately, the rails application often stopped working and took quite a moment to actually open the door. There was a remarkable delay between sending a client’s request to open the door and the door actually opening. Out of curiosity (because I was exploring the possibilities of using Qt for web services), I replaced the server component with a Qt app that ran on the thin client, which was performing stable for weeks and still is blazingly fast: The door appears to open instantly.

The next improvement was replacing the awkward combination of a thin client and the arduino board with an Olimex OLinuXino A20. Apart from reducing power consumption and size, we could now connect the relay directly to the GPIO of the Olimex board. Also, everything is now powered by a single USB charger. On the client side, we have written Qt and Swift clients for all Android and iOS devices.

Since this is also a learning experience for us figuring out how we can develop rock-solid apps on embedded devices, we are keen on sharing all the source code with you as free software. Get your copy here and let us know if you found it useful (or not, in any case :):

Happy hacking!

Today I managed to get a Bq Aquaris E4.5 Ubuntu Edition during the second flash sale of these phones. As someone who is really into the Ubuntu operating system, I waited for a long time to finally have an Ubuntu Phone. About a year ago I bought a Nexus 4, which was the reference development phone for Canonical, so I could flash it and run Ubuntu Phone. I used it for a few days and though it was an early work in progress version (which updated at least once daily), I was quite impressed. Swiping from the edges gets very intuitive after some short time and the design looks very promising.

If you merely look at the specs, there is nothing to be proud of. The hardware is mediocre, a bit more powerful than Galaxy S4 Mini, not a big deal.

Developing mobile apps can be frustrating

For me, as someone who is also developing mobile apps, I was very curious how developer-friendly the Ubuntu ecosystem is on mobile. If you say you are just a user and don’t care about that, keep in mind: Developer-friendly means developers struggle less with the tools they need to use and can concentrate better on getting real work done, leading to a better user experience, better stability and a greater variety of apps. I am sure that if you are a mobile app developer, you will be reminded now of how you struggle to get that stupid provisioning profiles set up, get lost in the objective-C hell of square brackets because Apple’s newest language called “Swift” is a giant green banana. XCode, the development tool for iOS apps, crashes randomly and stackoverflow is your friend when it comes to solving problems caused by inexplicable behaviour or frequent changes in predefined behaviour by Apple. When developing for Android, you’re left with a dead-slow simulator (so people usually use Android for x86 running in a VM or keep running their app on a real device) and clumsy Eclipse. Yes, there are alternatives to Eclipse, but each has its own quirks and cannot be regarded as a replacement, so you’re basically stuck. Android devices run Java, which theoretically isn’t slow. Practically, you need a quad-core processor to experience judder-free animations – quite ridiculous. Then there comes Firefox OS, the extreme version of every app is a website. Windows Phone? Noone wants Windows Phone. But I have to say: Working with Visual Studio and actually creating a Windows Phone app is smooth (although the tools seem to be very limited, but they’re stable), the process of submitting an app into the appstore is awful.

The two kinds of mobile apps

So, in conclusion, developing mobile apps can be challenging. Practically, there are just two main routes for the development of a mobile app:

  • You create a webapp, ie. a website that will be loaded in a container app, so the “app” is just a webbrowser window without the bar and tabs. Since most websites offer a mobile version anyways, this often allows to reduce the development costs. The disadvantage of this technique: You actually have to be online at the time you’re running the app or least trick around that limitation by storing offline sites. And the app still is a website, which has its own set of problems, like non-native controls, zooming behaviour, visual glitches, position problems and – especially on older devices – bad performance. If you write multiple containers, you can run your app on multiple devices saving the time to rewrite the whole app in a different programming language. So this is a trade-off between development speed/cost and app quality, but it’s better to have that kind of an app than any app at all.

  • You create a native app, ie. you are rewriting the app for each device. This requires you to literally rewrite the whole app, but you get native controls and better performance. On the other hand, you have to cope with the specialities of each development platform. Also, for an obvious reason, the development of native apps takes more time and thus will be more expensive.

Why Canonical did everything right

As a developer, I can only cheer Canonical for making the life of us developers a lot easier. They have recognized correctly how apps are being developed and are offering two ways to write your app:

  • Getting started quickly: Regarding the use case in which you quickly want to get your mobile website embedded in an app, they created a special template. Basically, it is a single file that you feed with some information about your app and it will appify your mobile website instantly.

  • The bleeding edge: You can write native apps with QML, which is basically a native app that can be developed as easy as a website (in the source code), but will compile to a native app. You can mix in C/C++ freely. With QtCreator, developers are supplied a well-known, excellent development tool. QML-apps can also run on Android, iOS and Windows Phone with no or few modifications to the source code.

  • Apps are distributed as packages through the software center of Ubuntu.

So, from a technical viewpoint, this sounds like something developers are waiting for a long time. It is undertstandable that Canonical tries to enter the smartphone market with a mid-priced budget phone, which probably is the best strategy from a marketing perspective.

Ubuntu Phone – cheapo or not?

While the Ubuntu Phone may appear like a cheap alternative to Android or iOS, it is an interesting piece of technology. Canonical is not generating a hype around void promises, rather they sneak in fully armed like a ninja. Their decisions on technologies are not based on suspect measures like the number of potential developers or the goal to create an isolated ecosystem, but rather on sane, rational arguments. That makes us developers happy and happy developers will write great apps.

Sometimes you want to transfer an url or very complicated password to you mobile phone. For example:

qrapp (speak “crap” 😉 ) does exactly that. It sits there readily in your traybar, as soon as you click on the icon it will automagically read the contents of you clipboard and generate a QR code.

Draw your mobile phone and launch your favorite QR reader – voila. Most QR readers will detect an URL and offer you to open it in the browser. qrcode-img qrapp is free software. Get it here: Download for MacOSX Yosemite Happy hacking!

There has been quite some resonance on the qt-pods project within the last days. I was busy helping onboarding a couple of projects and got invaluable help with the website design of by 9elements (although I changed details of the concept later, the design draft was overwhelmingly good). In the process Patrick Schneider developed the qt-pods badge:

Qt Pods Logo

This one is now used on github by many projects indicating they can be retrieved via qt-pods. While searching for pods that I could help onboarding, I stumbled upon some really interesing gems. Here are a few examples:

  • qtverbalexpressions is a library that lets you compose regular expressions with words.
  • qtbonjour is a bonjour service implementation ready for your Qt app.
  • qtwaitingspinner puts a fully customizable waiting spinner on any widget you give it as a parent.
  • qtlzma allows to encode/decode QByteArrays with LZMA.
  • qtqrencode generates QR code from any data you feed it, readily packed in a QImage.

The list goes on, currently there are about 20 projects ready to use at your fingertips, half of them have already been handed out under the umbrella of their original maintainers. I was offered help for building and packaging qt-pods for MacOS and incorporated suggestions from other developers. There are little, but still useful Qt projects all over the internet and it’s a sheer never-ending quest to find all of those and tune them for reuse. If you just take a look at under the widgets section, there are tons of widgets that want to be packaged and used. The only constraint here is time. What I need is some kind of avalanche effect in order to motivate developers to recognize the benefits.

Adding dependencies to your project can often be very painful, because technically, there are many ways to include foreign code. In very simple cases you might just copy over code, in most cases you are going to link against a library and sometimes you have to compare whole featuresets of frameworks and make up your mind, if the implications imposed by that dependency are a good trade-off compared to the benefits.

From a developer’s perspective, this is a nightmare. Usually you just want to flange a certain ability to your app, whether it is to decode an audio format, communicate via SOAP, send mails, speak to a certain REST API or analyze images, or whatever you are in need of. Luckily, there is a guy on github who did just what you need. Just imagine you could just click on a button and within seconds you would be up and running using his code. Scary? You might think so, but this is what qt-pods was designed for.

Calling qt-pods a package manager feels a bit odd, because this doesn’t describe precisely what it does. It is managing dependencies of your project via git’s submodules. While git submodules can be a tweaky thing in general and there are good reasons not to use git submodules in all cases, qt-pods does its best to orchestrate git not to make any mistakes.


qt-pods works within a qmake’s “subdirs”-project template, that is a pool of projects aligned next to each other (well, technically you can tweak it not to be like that). “Pods” are being compiled into static libraries and are then linked against your target application. With a bit of .pri-magic (which is not magic at all, if you take a deeper look), pods can specify their own dependencies to the final app. As the pods are git submodules, they are all independent repositories. That means, if you ever encounter foreign code to fail, you can fix it by yourself, but even better: you can generate patches or propagate these directly to the maintainer of the project. This is why the definition “package manager” fails, because what you actually get is not just an end product, a packaged result of some code, it *is* the code in a fully working environment. If included properly, the maintainer himself will include his code as a pod (from the same source like you, actually) and embed into a test project.

In order to get you started quickly, I sat down and defined fixed rules based on my previous experiences and then wrote an application that you can use to manage your pods. There is a graphical user interface and a command line version (which still needs some development), but they same reference to the same pod managing core: qt-pods-core. So, the qt-pods project uses qt-pods to manage itself. This is how both look like:



Learn more about qt-pods and get started today:

Yesterday a mail reached me on how to play back mp3 files with QJack. In general, there are two steps involved:

  1. Reading the mp3 file, decoding and filling a ringbuffer for playback
  2. Playing back samples with JACK

Let’s prepare the JACK client with QJack. In order to be able to store a whole mp3, we create a ringbuffer for 1000 seconds of playback. Then we register two output ports and connect them to the system playback.

void MainWindow::setupJackClient() {
    // Connect to JACK server

    // Create a 1000 seconds buffer (at 44,1kHz)
    _ringBufferLeft  = QJack::AudioRingBuffer(44100 * 1000);
    _ringBufferRight = QJack::AudioRingBuffer(44100 * 1000);

    // Register two output ports
    _outLeft     = _client.registerAudioOutPort("out_1");
    _outRight    = _client.registerAudioOutPort("out_2");


    // Activate client.

    // Connect automatically to system playback.
    _client.connect(_outLeft, _client.portByName("system:playback_1"));
    _client.connect(_outRight, _client.portByName("system:playback_2"));

As for the process method, we just want to take a bunch of sample from the ring buffer and put it into the output buffers when JACK requests it.

void MainWindow::process(int samples) {
    // Just shift samples from the ringbuffers to the output buffers.

For decoding, we have to specify the target format, namely sample rate, sample type, channels and codec. The sample rate is taken from the QJack client, the sample type has to be 16bit signed integer (ie the amplitude of a sample may vary between -65536 and +65536) and we want to have stereo. Since we are decompressing, we set “audio/x-raw” as the codec.

void MainWindow::setupMp3Decoder() {
    QAudioFormat targetAudioFormat;

Now, when the user selects a file, we pass it to QAudioDecoder and tell it to start decoding.

void MainWindow::on_toolButtonFileChoose_clicked() {
    QString fileName = QFileDialog::getOpenFileName(this, "Open mp3 file", QString(), "*.mp3");
    if(!fileName.isEmpty()) {

As soon as QAudioDecoder has a bunch of samples decoded, it will emit the bufferReady()-signal. We hook in with our own method to grab the buffer and pack the samples on top of those in the ringbuffer. We have to take care that we need to convert from signed 16-bit integers to 32 bit floats here.

void MainWindow::transferSamples() {
    QAudioBuffer audioBuffer =;
    if(audioBuffer.isValid()) {
        int frames = audioBuffer.frameCount();
        QJack::AudioSample left[frames];
        QJack::AudioSample right[frames];

        const QAudioBuffer::S16S *stereoBuffer = audioBuffer.constData();
        for (int i = 0; i < frames; i++) {
            left[i]     = (QJack::AudioSample)(stereoBuffer[i].left / 65536.0);
            right[i]    = (QJack::AudioSample)(stereoBuffer[i].right / 65536.0);

        _ringBufferLeft.write(left, frames);
        _ringBufferRight.write(right, frames);


That's it. Now you can launch the app, choose an mp3 file and it will start playing back via JACK. You can get the full working source code here:

For some time I am learning how to record music on GNU/Linux. A very handy tool for managing your JACK connections is qjackctl, a small tool that allows you to set up the JACK audio server, draw connections between client and a lot more. There are more tools that do that, but none of them did the job as good as qjackctl, despite the fact that qjackctl was not the most appealing candidate in terms of visual appearance.

This led me to dive into the qjackctl source code and see what’s going on inside. Well, there seems to be a reason qjackctl has stuck on version 0.3.x. qjackctl serves its purpose while the code was hard to maintain. The original author, Rui Nuno Capela, admitted that himself. At the same time, I was developing QJack for a different purpose, a Qt/C++ wrapper around the libjack C API. In an object oriented environment you do not want to have global callback functions, even more, with a Qt based program, you’d like to have signals and slots. I thought cleaning up qjackctl and integrating QJack to make an example of how you can benefit from using QJack (in terms of stability and clean code) was a good idea.

It was not. I spent countless hours refactoring code, but it’s almost done. And now that I can start rebuilding (and adding!) features, the fun begins. I started with the connections panel. Here is a direct comparison of the original version and the improved one.



At first sight, pretty similar – under the hood, entirely different. On the visual side I didn’t want to reinvent the wheel, I just improved what was already there:

  • Alternating row color help you to visually assign a connection to the port’s name
  • Antialiasing on port connections
  • The scroll bar of the left tree widget moved to the left in order to not distract the visual connection between cable and port
  • Audio and midi ports can be viewed in a single view rather than in separate tabs
  • It is now possible to choose between four different selection modes rather than just single selection, so you can choose multiple ports and connect them instead of repeatedly selecting another port and clicking connect or dragging
  • In addition to expanding all items, you can collapse all items
  • Better icons (where applicable)
  • No gap between cables and ports
  • Cable colors now have a meaning: Red color (red = positive, source) means you selected a send port that the cable is connected to, blue color (blue = negative, sink) indicates you selected a return port that the cable is connected to, green means that both selected ports are connected through that cable.
  • The “cable area” is scrollable. If you hover over it, scrolling will scroll both port views by the same amount

In conclusion, being flexible through refactoring code that does not directly belong to the user interface lowered a lot of technical barriers for cleaning up and extended the traditional functionality with new, meaningful features.

You can following qjackctl refactoring here:
If you are interested in QJack, see here: