Skip to content


FOSS Qt Releases Delayed by up to 12 Months?

On 8 April 2020, Olaf Schmidt-Wischhöfer wrote in an email to the KDE community (emphasis mine):

[…] last week, [The Qt Company] suddenly informed both the KDE e.V. board and the KDE Free QT Foundation that the economic outlook caused by the Corona virus puts more pressure on them to increase short-term revenue. As a result, they are thinking about restricting ALL Qt releases to paid license holders for the first 12 months.

To be clear: Nothing has been decided yet. I certainly hope that this “thinking” by The Qt Company remains just that: thinking. But I am not quite sure.

Read More »FOSS Qt Releases Delayed by up to 12 Months?

Creating Simple Installers with CPack

In my recent post Benefits of a Relocatable Qt, I explained how to relocate Qt from a build server to a developer PC and from the PC to an embedded system. Qt is installed in three different locations. My solution has two small deficiencies. First, it sets the install rpath to an absolute path and restricts the installation to this absolute path. Second, it forces us to create a tarball of the installation directory on the PC manually. Let us fix these two deficiencies.

Read More »Creating Simple Installers with CPack

Benefits of a Relocatable Qt

Bob builds Qt for the development team on a fast compute server. He packs Qt into a tarball and hands the tarball to his teammates. Alice installs the Qt tarball on her PC in a directory that differs from the installation directory used by Bob. As the target embedded system runs on an AMD Ryzen SoC with x86_64 architecture like the build server and the development PC, Alice installs Qt on the target system – yet in another directory. She can then try out the latest changes of her app directly on the target system. As Qt is relocatable since version 5.14, Alice’s and Bob’s jobs have become quite a bit easier.

Read More »Benefits of a Relocatable Qt

Less Love for FOSS Qt Users

From Qt 5.15, The Qt Company make their offering a bit more inconvenient for FOSS users. They announced three changes:

  • A Qt account is mandatory to download binary Qt packages. The offline installer is not available to FOSS users any more.
  • LTS (long-term support) releases are not available to FOSS users, once the next minor or major release is out.
  • Small business pay 499 USD per year, if their yearly revenue is less than 100,000 USD and they have less than five employees.

What do these changes mean for the development of Qt embedded Linux systems under LGPLv3?

Read More »Less Love for FOSS Qt Users

Safe-Guarding the (L)GPL Future of Qt

The little known KDE Free Qt Foundation makes sure that Qt stays free and open-source. It guarantees that all Qt modules currently licensed under LGPLv3 must continue to be available under LGPLv3 in the future. This covers all modules from Qt Essentials and many add-on modules. If The Qt Company discontinued the FOSS version of Qt, the Foundation would have the right to make Qt available under the BSD license. This is a very powerful protection of free and open-source Qt.

Read More »Safe-Guarding the (L)GPL Future of Qt

Detecting Overdraw in QML HMIs with GammaRay

Overdraw happens when one QML item fully eclipses another QML item. The QML renderer always draws both items, although there is no need to draw the eclipsed item. You must help out the renderer by explicitly setting visible: false on the eclipsed item.

On embedded systems, heavy overdraw makes animations or flicking jerky. In the worst case, it freezes your HMI. Fortunately, the Qt experts at KDAB developed a tool, GammaRay, which makes detecting overdraw a piece of cake. I’ll show you how to build GammaRay, how to detect overdraw in the home screen of a harvester HMI, and how to fix the overdraw.

Read More »Detecting Overdraw in QML HMIs with GammaRay

Comparing Two Floating-Point Numbers

The mathematician Leopold Kronecker is believed to have said:

God made the integers, all else is the work of man.

And Kronecker didn’t even know the floating-point numbers “made” for computers. Comparing two numbers of type float or double in C++ and related languages is a source for regular errors. When are the if-conditions in the following code snippet true?

float actual = calculate(10.0f, 0.2f, 45); // 10 - 0.2 * 45 = 1
if (actual == 1.0f) {
    // is this ever executed?
if (actual - 1.0f == 0.0f) {
    // is this ever executed?

The function calculate produces the result 10 – 0.2 * 45 = 10 – 9 = 1 – at least for human beings. So, both conditions should be true. However, they are both false.

If we turn on the warning -Wfloat-equal, the compiler will warn us that comparing floating point with == or != is unsafe. The compiler tells us what is wrong, but not how to fix it. I’ll explain why the above “solution” is wrong, why another obvious “solution” is nearly as bad, and why even the Qt function qFuzzyCompare can still be improved.

Read More »Comparing Two Floating-Point Numbers