Qt6 - die Neuerungen im Überblick

Ein turbulentes Jahr 2020 endete mit dem ersten Release der neuen Major-Version 6 des bekannten UI-Frameworks Qt. Wir schauen uns die neue Version im Detail an.

Rund acht Jahre nach dem Umstieg auf Version 5 betrachten viele die neue Version 6 argwöhnisch. Herausforderungen technischer Art sind bei einer Versionsumstellung nicht auszuschließen - Fortschritt geht bekanntlich mit Veränderung einher. Zusätzlich bringt das Update weitreichende Änderungen im Lizenzierungsmodell mit. Die Ankündigung, LTS-Versionen den kommerziellen Nutzerinnen und Nutzern vorzubehalten, schürt jedoch Bedenken über die Zukunft des Frameworks. Vor allem die Stimmen aus dem Open Source-Bereich sprechen eine deutliche Sprache. Aber ein Schritt nach dem anderen…

The Qt Company

Ursprünglich zur norwegischen Firma Trolltech gehörend, wurde das Framework an Nokia, später dann an Digia verkauft, im Jahr 2014 in ‚The Qt Company‘ umbenannt und anschließend an die Börse gebracht. Unabhängig davon hat sich Qt bestens entwickelt und ist aus der Softwareentwicklung nicht wegzudenken. Trotz der vielen strategischen und technischen Änderungen erfreut sich das Framework einer großen Beliebtheit, nicht zuletzt durch die große Open Source Community und die Vielzahl an Einsatzmöglichkeiten.

Die Änderungen rund um das neue Release setzen sich zum Ziel, die breit gefächerten Anforderungen der bunt gemischten Nutzungsszenarien des Frameworks abzudecken.

Das Qt Design Studio und Design-Development-Workflow

In der neuen Major-Version konzentriert sich das Qt Design Studio vor allem auf Verbesserungen der Oberfläche und soll die Lücke zwischen Design und Entwicklung weiter schließen. Die bereits zuvor integrierte 3D-Unterstützung im Qt Design Studio bekommt einen integrierten 3D-Editor, mit dem nun 3D-Elemente in klassischen UIs Platz finden können.

Bei Ergosign nutzen wir das Qt Design Studio eher selten. Nicht zuletzt, weil unser Ergosign-charakteristischer Design-Development-Workflow sich im Tagesgeschäft nicht auf ein einzelnes Framework beschränken lässt.

Hier gibt's mehr zum Thema Development bei Ergosign.

Cross-Kompatibilität und Skalierbarkeit sind weiterhin die Kerneigenschaften von Qt. Applikationen reichen von ganzen Desktop-Suiten bis hin zu Embedded-Systemen, von mobilen Applikationen auf den Smartphones Tausender bis hin zu komplexen Maschinensteuerungen, genutzt von wenigen Spezialisten.

Mit dem Qt 6.0 Release soll diese Diversifizierung unterstützt und vorangetrieben werden. Es ist deshalb nicht verwunderlich, dass zu den größten technischen Neuerungen der Support des

C++17-Standards und CMake als Buildsystem gehören. Ein neuer Graphik-Abstraktionslayer entkoppelt Qt von OpenGl und das Qt Core-Modul erfreut sich einiger interessanter Verbesserungen.

Welche Verbesserungen bringt der neue Graphik-Abstraktionslayer?

Das Qt Rendering Hardware Interface ist eine interessante strategische Entscheidung der Qt Company. Bisher nutzt Qt nur OpenGL als hardwareunterstützte Grafikbeschleunigung.

Das QRHI regelt als Abstraktionsschicht zum einen den Zugriff auf die nativen Grafikschnittstellen der jeweiligen Laufzeitumgebung und bietet zum anderen zur Applikation ein vereinheitlichtes Interface.

Für unsere Kunden bieten wir oft Unterstützung bei der Evaluation der Hardware und Bibliotheken für deren spezifische Use Cases an.

Somit ist die Möglichkeit, etwas anderes neben OpenGL nutzen zu können, grundsätzlich eine tolle Sache. Unter Linux bleibt OpenGL in den meisten Fällen jedoch das Mittel der Wahl.

Was bringt Qt 6 noch mit?

Die Möglichkeit, CMake anstatt QMake als Buildsystem zu verwenden, besteht bereits seit einiger Zeit - in unserem Projektalltag halten sich beide die Waage. Qt hat jedoch bisher immer auf das leichtgewichtigere QMake gesetzt. CMake löst QMake nun als Default ab und Qt 6 selbst wird mit CMake gebaut.

Für die Projekte, die aktuell QMake als Buildsystem nutzen, ist diese Neuerung eher uninteressant. Legt man den aktuellen Releasezyklus zugrunde, ist eine Umstellung zum jetzigen Zeitpunkt nicht notwendig, da Qt die Unterstützung von QMake als Buildsystem für die gesamte Majorversion angekündigt hat. Für neue Projekte mit Qt 6, bei denen Qt aus den Sourcen selbst gebaut wird, ist CMake nun unumgänglich.

Neben den genannten größeren Neuerungen bringt Qt 6 zahlreiche Änderungen in den einzelnen Modulen mit sich. Die Qt Container-Klassen und das Concurrency Handling wurden überarbeitet und Qt verfügt nun über zusätzliche Styles für natives Look & Feel für Windows- und MacOS-Applikationen. Vielversprechend ist ebenfalls die Erweiterung des QML-Bindingkonzepts, welches nun auch in C++ genutzt werden kann.

Open Source vs. kommerzielle Lizenz

Mit der neuen Version leitet The Qt Company auch eine neue Lizenzpolitik ein. Es werden kostenlose Open-Source-Lizenzen und kommerzielle Lizenzen unterschieden. Statisches Linken gegen die Qt-Bibliotheken und der Zugriff auf die LTS-Versionen bietet allerdings nur die kommerzielle Lizenz. Das bedeutet für die Nutzer:innen der Open-Source-Lizenz ein regelmäßigeres Upgraden auf die aktuelle Version.

Ein Großteil der Qt-Module steht unter der GPLv3, die Tivoisierung explizit untersagt.

Bei Desktop-Applikationen ist dynamisches Linken unproblematisch, da ein Austausch der Bibliotheken über das jeweilige Betriebssystem ohne weiteres möglich ist. Allerdings ist ein Austausch der Bibliotheken für unsere Kunden mit Embedded-Projekten immer wieder Grund zur Sorge. Eine Offenlegung des Quellcodes reicht dabei nicht aus, um lizenzkonform zu sein. Es muss auch die technische Möglichkeit für den Austausch des Quellcodes bestehen.

Bei Technologieentscheidungen im Embedded-Kontext ist es meist nur erschwert möglich, dem User den Austausch des Quellcodes zu ermöglichen. Die Frage nach der kommerziellen Lizenz wird hier dementsprechend häufiger gestellt.

Was kostet die kommerzielle Lizenz?

Die Kosten einer kommerziellen Lizenz im Desktop-Bereich lassen sich anhand der Qt-Webseite einfach kalkulieren - es wird ein monatlicher Betrag pro Entwickler:in fällig.

Für eingebettete Systeme sind die Lizenzkosten weniger gut ersichtlich. Die kommerzielle Lizenz für eingebettete Systeme setzt sich zum einen aus Entwicklerlizenzen und zum anderen aus Distributionskosten zusammen, die auf der Absatzmenge des Produktes basieren. Für beide gibt Qt keinerlei Anhaltspunkte. Denn die Absatzmenge (und der Preis des Produktes) kann in unterschiedlichen Kontexten stark variieren. Die Absatzmenge eines Consumer-Produktes mit integrierter Applikation bewegt sich eher im Bereich der Hunderttausend, ist jedoch nur bedingt mit einem eingebetteten System im industriellen Kontext zu vergleichen, bei dem die Anzahl der verkauften Elemente sich im unteren zweistelligen Bereich bewegt, ein Gerät aber Millionen kosten kann.

Mein Fazit: Lohnt das Update auf Qt 6?

Wie immer im Leben: Es kommt darauf an…

Erfahrungsgemäß treten viele unserer Kunden einem Update einer Majorversion eher zögernd und vorsichtig entgegen, da erhebliche Aufwände und Probleme entstehen können. Eine neue Majorversion beinhaltet noch mehr substanzielle Änderungen, sodass die Portierung von bestehenden Qt-Applikationen sowieso hinausgezögert wird.

Für eingebettete Systeme gibt es neben Qt wenig Alternativen, und dennoch führt die Unsicherheit über Kosten und Lizenzen nicht selten zu einer Entscheidung gegen das Framework. Erfahrungsgemäß ist die Entwicklung mit Qt circa 30% effizienter, verglichen mit einer Webentwicklung. Diese Argumentation ist ohne Einschätzung über die tatsächlichen Lizenzkosten jedoch oft nicht ausreichend.

Je nach Projekt ist es unumgänglich, zusammen mit unseren Kunden die individuellen Aspekte und Anforderungen zu bewerten. Im gemeinsamen Dialog - auch mit der Qt Company - kann so eine sinnvolle Evaluierung stattfinden.

Alles in allem bringt Qt 6 viele positive Änderungen, für die es Zeit geworden ist. C++17 ist nun bereits vier Jahre alt und CMake schon lange ein Standard. Die strategische Ausrichtung von Qt, sich als zentraler, vernetzender Baustein zwischen den diversen Einsatzmöglichkeiten zu positionieren und Developer, Designer, User und Maintainer zusammenzubringen, ist nachvollziehbar. Inwieweit sich jedoch die Lizenzpolitik auf die Zukunft des Frameworks auswirkt, bleibt abzuwarten.