Qt6 - under the hood

A turbulent 2020 ended with the first release of the new major version 6 of well-known UI framework Qt. We take a closer look at the new version.

Around eight years after the transition to version 5, many are greeting the new version 6 with suspicion. Technical challenges cannot be ruled out when switching versions - progress involves change, after all. What’s more, the update comes with far-reaching changes to the licensing model. The announcement that LTS versions would be reserved for commercial users is fueling doubt as to the framework’s future. Voices from the open source sector in particular are not mincing their words. But first thing’s first…

The Qt Company

Originally part of Norwegian company Trolltech, the framework was sold to Nokia then Digia. It was renamed “The Qt Company” in 2014 and finally listed on the market. Regardless, Qt’s development was ideal, and it is now an integral part of software development. Despite many strategic and technical changes, the framework enjoys a high level of popularity, not least thanks to the large open source community and variety of application options.

The changes surrounding this new release aim to cover the broad needs of the framework’s diverse user scenarios.

The Qt Design Studio and design development workflow

In the new major version, the Qt Design Studio concentrates primarily on improvements to the interface and intends to further close the gap between design and development. The 3D support already integrated into the Qt Design Studio is getting an integrated 3D editor that can now be used to add 3D elements to classic UIs.

At Ergosign, we use Qt Design relatively rarely. Not least because our characteristic Ergosign design-development workflow cannot be limited to one single framework in our daily work.

Here is more about Development at Ergosign.

Cross-compatibility and scalability are still Qt’s key characteristics. Applications range from whole desktop suites to embedded systems, from mobile applications on thousands of smartphones to complex machine controls used by a handful of specialists.

The release of Qt 6 both supports and drives this diversification. It is, therefore, no wonder that the biggest technical changes include the support of desC++17 standards and CMake as a build system. A new graphic abstraction layer uncouples Qt from OpenGI and the Qt core module has been treated to a few interesting improvements.

What improvements does the new graphics abstraction layer bring?

The Qt Rendering Hardware Interface is an interesting strategic decision from The Qt Company. Up to now, Qt has only used OpenGL as hardware-supported graphics acceleration.

As an abstraction layer, the QRHI regulates access to native graphic interfaces for the relevant runtime environment and also offers a coherent interface for the application.

We often offer our clients support in the evaluation of hardware and libraries for their specific use cases

So the opportunity to use something else as well as OpenGL is fundamentally great. OpenGL will, however, remain the first choice among Linux.

What else does Qt 6 have?

The opportunity to use CMake instead of QMake as a build system has existed for quite some time - they are both equally represented in our everyday project work. However, Qt has always used the more lightweight QMake up to this point. CMake has now taken over QMake as default, and Qt 6 itself was built with CMake.

For the projects currently using QMake as their build system, this change is rather uninteresting. If you are currently in a release cycle, transitioning at this point is not necessary as Qt has announced it will support QMake as a build system throughout the whole of this major version. For new projects with Qt 6, whereby Qt is built from the sources itself, CMake is now unavoidable.

Alongside the major changes already outlined, Qt 6 comes with plenty of changes to individual modules. The Qt Container classes and Concurrency Handling have been overhauled and Qt now has additional styles for a native look & feel for Windows and MacOS applications. The expansion of the QML binding concept, which can now also be used in C++, is promising too.

Open source vs. commercial license

With the new version, The Qt Company has also introduced a new license policy. They differentiate between free open-source licenses and commercial licenses. Only the commercial license offers static linking to Qt libraries and access to LTS versions. For open-source license users, this means more regular upgrading to the latest version.

The majority of Qt modules comes under GPLv3, with tivoization explicitly prohibited.

Dynamic linking is unproblematic in desktop applications, as libraries can simply be exchanged via the relevant operating system. However, exchanging libraries for our clients with embedded projects is again a cause for concern. Publishing the source code is not enough to comply with the license. There must be the technical possibility of exchanging the source code. When it comes to technological decisions in an embedded context, it is usually difficult to allow the user to exchange the source code. The question of the commercial license is cropping up more frequently here.

What does a commercial license cost?

The cost of a commercial desktop license can simply be calculated on the Qt website — a monthly sum is charged per developer.

The license costs for embedded systems are less transparent. The commercial license for embedded systems is based on developer licenses on one hand and distribution costs related to the product’s sales volume on the other. Qt provides no clues for either. After all, sales volume (and product price) can vary greatly in various contexts. The sales volume of a consumer product with integrated application ranges in the hundreds of thousands but embedded systems in an industrial context can only be compared to an extent, and the number of sold elements may be in the low double figures but one device may cost millions.

To sum it up: is updating to Qt 6.0 worth it?

As always in life… it depends.
Based on experience, many of our clients tend to be cautious and wary of major version updates, as both costs and problems can be significant. A new major version contains even more substantial changes, so the porting of existing Qt applications is delayed either way.

Other than Qt, there are few alternatives when it comes to embedded systems, and the uncertainty surrounding costs and licenses is frequently leading to decisions to eschew the framework. Based on experience, development is around 30% more efficient with Qt in comparison to web development. This argument is often not enough without an estimation of the actual license costs.

Depending on the project, evaluating the individual aspects and requirements with our clients is unavoidable. And such a meaningful evaluation is possible through dialogue - even with The Qt Company.

All in all, Qt 6.0 comes with many positive changes made at the right time. C++17 is now four years old and CMake has long become a standard. QT’s strategy of positioning itself as a central, network-forming building block between various application options and of bringing together developers, designers, users, and maintainers is understandable. But it remains to be seen to what extent the license policy will impact the framework’s future.