Qt 5 vs. Qt 6: Was sich wirklich geändert hat – und was es für Embedded-Projekte bedeutet

Kurz gesagt: Qt 6 ist kein neues Framework. Es ist Qt 5 mit drei tiefen Änderungen: CMake als Standard-Build-System, C++17 als Untergrenze und ein Grafik-Stack, der nicht mehr von OpenGL ausgeht. Für eine Qt-Widgets-Anwendung auf dem Desktop ist der Unterschied kaum sichtbar. Für eine Qt-Quick-Oberfläche auf einem Embedded-Board schon – eigene Shader, eigener OpenGL-Code und eine Handvoll Module entscheiden darüber, ob der Umstieg Tage oder Monate dauert. Und der Abstand wächst: Neue Funktionen und Fehlerbehebungen landen in Qt 6, Qt 5.15 ist die Endstation.

Dieser Artikel vergleicht die beiden Versionen. Wie der Umstieg Stufe für Stufe abläuft, steht in unserem Fahrplan für die Migration von Qt 5 auf Qt 6.

Der Vergleich in einer Tabelle

	Qt 5 (5.15)	Qt 6
Build-System	qmake als Standard, CMake unterstützt	CMake als Standard; qmake baut Anwendungen weiterhin
C++-Standard	C++11	C++17
Rendering in Qt Quick	direkt auf OpenGL (RHI nur als Vorschau zum Einschalten)	über die RHI: OpenGL, Vulkan, Metal oder Direct3D, je nach Plattform
Eigene Shader	GLSL als String direkt im QML	vorkompilierte .qsb-Dateien aus den Qt Shader Tools
Grafikeffekte	Qt Graphical Effects	MultiEffect (seit 6.5); ein Teil der alten Effekte in Qt5Compat
QTextCodec, QRegExp	Teil von Qt Core	ins Modul Qt5Compat verschoben
Container	Größen als int, QList und QVector getrennt	Größen als qsizetype, QList und QVector sind dieselbe Klasse
Property-Bindings	in QML	in QML und in C++ (QProperty)
High-DPI-Skalierung	zum Einschalten	immer aktiv
Stand	letztes Qt-5-Release	aktive Entwicklung mit LTS-Releases

Die meisten Zeilen sind in einer typischen Codebasis höchstens einen Tag Arbeit. Zwei nicht – und beide liegen im Grafik-Stack.

Was gleich bleibt

Das Fundament hat sich nicht bewegt. Objektmodell, Signale und Slots, Event-Loop und Modulstruktur sind, was sie waren. Die Sprache QML ist weitgehend unverändert – Qt 6 ergänzt eher, etwa Imports ohne Versionsnummer, als dass es wegnimmt. Qt Widgets behält sein Rendering-Backend: Laut Qt-Dokumentation ist das Grafik-Backend für Widget-Anwendungen unverändert – nur die jetzt immer aktive High-DPI-Skalierung kann das Aussehen bei gebrochenen Skalierungsfaktoren verändern. Eine Widgets-Anwendung braucht also vor allem mechanische Portierung, die sich in weiten Teilen mit den Clazy-Portierungschecks automatisieren lässt.

Auch die Plattform-Plugins, auf die es unter Embedded Linux ankommt, gibt es weiterhin: EGLFS, LinuxFB und Wayland. Wenn Ihr Gerät heute direkt in eine Qt-Anwendung im Vollbild startet, kann es das mit Qt 6 genauso – unser Artikel über Qt mit EGLFS gilt für beide Versionen.

Der eigentliche Unterschied: die Grafik

In Qt 5 hat Qt Quick direkt mit OpenGL gerendert. In Qt 6 rendert es über die RHI, das Rendering Hardware Interface – eine Abstraktion, die je nach Plattform auf Vulkan, Metal, Direct3D oder OpenGL abbildet. Solange eine Anwendung nichts anderes verlangt, wählt Qt Quick einen Standard für die Plattform. Unter Embedded Linux ist das meist weiterhin OpenGL ES, an der Oberfläche ändert sich also wenig. Darunter ändern sich drei Dinge.

Shader. Ein ShaderEffect nimmt keinen GLSL-Quelltext als String mehr an. Shader werden jetzt mit den Werkzeugen aus dem Modul Qt Shader Tools zu .qsb-Dateien vorverarbeitet, die für jede Grafik-API eine eigene Variante enthalten; der ShaderEffect verweist auf diese Dateien. Die CMake-Funktion qt_add_shaders erzeugt diese Varianten standardmäßig, das Kommandozeilenwerkzeug qsb ohne weitere Angaben (--qt6 oder --glsl) dagegen nur SPIR-V – ein so gebauter Shader funktioniert mit Vulkan und scheitert auf einem Board mit OpenGL ES. In einer industriellen Bedienoberfläche mit eigenen Anzeigeinstrumenten, Leuchteffekten und Übergängen ist das Umstellen aller Effekte neben Qt Quick Controls 1 oft der größte Einzelposten der Migration. Auch Qt Graphical Effects gibt es nicht mehr: Ein Teil lebt als Qt5Compat.GraphicalEffects weiter, und seit Qt 6.5 deckt MultiEffect die üblichen Fälle wie Unschärfe, Schatten und Einfärben in einem Element ab.

Eigener OpenGL-Code. Alles, was direkt mit OpenGL spricht, braucht einen zweiten Blick. Die OpenGL-Hilfsklassen sind ins Modul Qt OpenGL gewandert, QOpenGLWidget nach Qt OpenGL Widgets. In Qt Quick funktioniert QQuickFramebufferObject nur, solange der Szenengraph tatsächlich mit OpenGL rendert; eine Anwendung, die darauf aufbaut, muss das mit QQuickWindow::setGraphicsApi(QSGRendererInterface::OpenGL) erzwingen. Code, der in beforeRendering() oder afterRendering() eigene OpenGL-Aufrufe absetzt, muss sie jetzt in beginExternalCommands() und endExternalCommands() einschließen, damit der zwischengespeicherte Zustand des Renderers stimmig bleibt. Und ein Underlay – ein Video- oder Kamerabild unter der Oberfläche, auf Embedded-Geräten häufig – wandert nach beforeRenderPassRecording(): Qt 6 kann das Löschen des Farbpuffers nicht mehr überspringen, was vorher gezeichnet wurde, ist also weg.

Start. Grafik-Pipelines zu erzeugen, kostet mit den GPU-Treibern kleiner SoCs Zeit. Unter OpenGL legt Qt kompilierte Shader-Programme schon seit 5.9 auf dem Datenträger ab. Qt 6.5 ersetzt das durch einen Pipeline-Cache für jede Grafik-API und macht ihn ausdrücklich steuerbar, sodass eine Anwendung eine vorbefüllte Cache-Datei mitliefern kann, die auch den allerersten Start beschleunigt. Der Cache greift nur, wenn Gerät und Treiber zu denen passen, auf denen er entstanden ist – auf dem Desktop ein Glücksspiel, bei einer Geräteserie mit einem SoC und einem BSP genau der Normalfall. Wenn Ihr Gerät ein Budget für die Boot-Zeit hat, sollten Sie das kennen – den Rest dieses Budgets behandeln wir unter Boot-Zeit von Embedded Linux optimieren.

Zwei kleinere Punkte runden das Bild ab. Geräte ohne GPU können Qt Quick weiterhin über die Software-Adaption ausführen, die allerdings keine ShaderEffect-Elemente und keine Partikel rendert. Und einige Module hängen selbst an OpenGL: In Qt Charts rendern beschleunigte Serien nur, solange Qt Quick OpenGL verwendet, und Qt Data Visualization unterstützt nur das OpenGL-Backend. Beide sind seit Qt 6.10 abgekündigt; der Nachfolger Qt Graphs bringt Anleitungen für die Migration von beiden Modulen mit und ist das, was neuer Code verwenden sollte.

Module: entfernt, neu geschrieben, zurückgekehrt

Qt 6.0 kam ohne eine lange Liste von Qt-5-Modulen. Wer sich Qt 6 Anfang 2021 angesehen und deshalb verworfen hat, sollte noch einmal hinsehen – die meisten sind zurück.

• Dauerhaft entfernt oder ersetzt: Qt Script (an seine Stelle tritt die JavaScript-Engine von Qt QML, QJSEngine), Qt XML Patterns, Qt Quick Controls 1, Qt Graphical Effects und die plattformspezifischen Extras-Module für macOS, Windows, X11 und Android, deren Funktionen größtenteils in andere Module gewandert sind.
• Zurück in Qt 6.1: Qt Charts, Qt Data Visualization, Qt Virtual Keyboard, Qt Lottie und Qt SCXML, zusammen mit dem neuen Modul Qt State Machine, das die früher in Qt Core enthaltene State-Machine-API aufnimmt.
• Zurück in Qt 6.2, dem ersten LTS-Release: Qt Multimedia, Qt Bluetooth, Qt NFC, Qt Positioning, Qt Serial Port, Qt Serial Bus, Qt Remote Objects, Qt Sensors, Qt WebChannel, Qt WebEngine, Qt WebSockets und Qt WebView.
• Qt 6.5: Qt Location kehrte als Technologievorschau zurück, daneben die neuen Module Qt GRPC und Qt Protobuf, ebenfalls als Vorschau.

„Zurück“ heißt nicht immer „unverändert“. Qt Multimedia wurde grundlegend überarbeitet: Geräteerkennung, Audio auf niedriger Ebene, Wiedergabe, Aufnahme und die Videoausgabe haben alle eine geänderte API. Für ein Gerät mit Kamera oder Videopfad verdient dieses Modul eine eigene Bewertung. Ein Embedded-Detail obendrauf: Seit Qt 6.5 ist das FFmpeg-Backend auf den meisten Plattformen Standard, aber nicht für Yocto-basierte Builds – prüfen Sie auf dem Gerät, welches Backend Ihr Image tatsächlich mitbringt.

Auch die Lizenz verdient einen Blick pro Modul. Mehrere Zusatzmodule – darunter Qt Graphs und Qt Virtual Keyboard – gibt es nur unter GPLv3 oder einer kommerziellen Lizenz, was bei geschlossener Geräte-Firmware ins Gewicht fällt. Was das speziell für die Bildschirmtastatur bedeutet, haben wir im Artikel über Qt Virtual Keyboard auf Embedded-Geräten ausführlich behandelt.

Sprache und Kernbibliotheken

Qt 6 verlangt C++17. Mit einer aktuellen Toolchain ist das kein Thema; mit einem in die Jahre gekommenen Hersteller-SDK kann es die Qt-Migration zuerst in ein Toolchain-Update verwandeln. Im Gegenzug darf die Codebasis die Sprachmittel nutzen, die wir in modernes C++ für Embedded-Systeme beschreiben.

Die Container wurden zusammengeführt: QList und QVector sind jetzt eine Klasse, und Größen sind qsizetype statt int. Das meiste davon kompiliert unverändert; in 64-Bit-Builds kann Code, der eine Größe in einem int ablegt, Konvertierungswarnungen erzeugen. Der Umgang mit Textkodierungen hat sich von Codecs gelöst – QTextCodec lebt in Qt5Compat weiter, und QTextStream::setCodec() ist setEncoding() gewichen.

Die interessantere Neuerung sind bindbare Properties in C++. Mit QProperty funktioniert der Binding-Mechanismus, den QML schon immer hatte, auch in C++: Ein Wert berechnet sich neu, wenn sich seine Eingaben ändern, ohne handgeschriebene Signal-Verdrahtung. Für Datenmodelle hinter einer Bedienoberfläche ist das eine echte Vereinfachung – aber eine Ergänzung, die Sie schrittweise übernehmen können, keine Pflicht bei der Portierung.

Support und Wartung: Der Abstand wächst

Qt 6.0 erschien Ende 2020, und die Qt-6-Linie hat seitdem mehrere LTS-Releases hervorgebracht: 6.2, 6.5, 6.8 und seit September 2026 6.12, das The Qt Company fünf Jahre lang pflegt. Qt 5.15 ist das letzte Qt-5-Release. Sein kommerzieller Langzeit-Support endete am 26. Mai 2025; seitdem gibt es nur noch kostenpflichtige Extended Security Maintenance.

Auf einem Embedded-Gerät erzwingt der Support-Kalender den Umstieg selten allein. Das Build-System tut es. Unter Yocto kommt Qt 6 über den Layer meta-qt6, den The Qt Company pflegt. Ein altes Qt 5 in einem neueren Yocto-Release am Laufen zu halten – neuerer Compiler, neuere Systembibliotheken –, ist Zusatzarbeit, die Ihnen niemand abnimmt. Der Zeitpunkt kommt meist mit einem neuen SoC, der ein neueres BSP braucht.

Dazu kommt die Regulierung. Der Cyber Resilience Act verpflichtet Hersteller von Produkten mit Datenverbindung – zu einem Netzwerk oder zu einem anderen Gerät, wozu auch ein USB- oder serieller Service-Anschluss zählt –, Schwachstellen über den Supportzeitraum des Produkts zu behandeln. Ein Gerät, das ein Open-Source-Qt 5.15 ohne Sicherheitsupdates ausliefert, macht diese Pflicht schwer erfüllbar – die weiteren Anforderungen haben wir unter Cyber Resilience Act und sichere OTA-Updates beschrieben.

Wann Qt 5.15 vertretbar ist – und wann nicht

Bei Qt 5.15 zu bleiben, ist vertretbar, wenn …	Der Umstieg auf Qt 6 ist fällig, wenn …
das Produkt nur noch gewartet wird und das Verkaufsende absehbar ist	das Produkt noch jahrelang weiterentwickelt wird
Hardware und BSP eingefroren sind	ein neuer SoC oder ein Yocto-Upgrade ansteht
das Gerät überhaupt keine Datenverbindung hat oder ein Supportvertrag die Sicherheitsupdates abdeckt	das Gerät eine Datenverbindung hat und unter den Cyber Resilience Act fällt
für die Oberfläche keine neuen Funktionen geplant sind	die Oberfläche Funktionen oder Module braucht, die es nur in Qt 6 gibt
	das Team mehr Zeit mit Workarounds verbringt als mit Funktionen

Es gibt einen Mittelweg, der sich in jedem Fall auszahlt. Auf Qt 5.15 wechseln, die Deprecation-Warnungen abarbeiten und den Build auf CMake umstellen, ist sinnvolle Arbeit, selbst wenn der eigentliche Wechsel auf Qt 6 erst ein Jahr später kommt – und es sind genau die ersten beiden Stufen des Migrationsfahrplans.

Wie groß der Umstieg für Ihr Projekt ist

Vier Fragen bestimmen den Umfang einer Migration besser als jede Zeilenzählung. Wie viel QML gibt es, und baut es auf Qt Quick Controls 1 auf? Hängt die Anwendung an Modulen, die neu geschrieben wurden, allen voran Qt Multimedia? Wie viele eigene Shader und wie viel handgeschriebenen OpenGL-Code enthält sie? Und gibt es automatisierte Tests auf echter Hardware, die einen grafischen Rückschritt überhaupt sichtbar machen?

Wenn Sie die Antworten haben, lässt sich der Aufwand benennen. Wenn nicht, liefert sie ein zeitlich begrenzter Spike an Ihrem Code – damit beginnt unsere Qt-Migration von Qt 5 auf Qt 6. Wenn Ihr Team die Migration lieber selbst durchführt, behandelt unsere Qt/QML-Schulung sie auf Wunsch als eigenen Block.

Fazit

Qt 6 ist dasselbe Framework auf einem modernen Fundament: CMake, C++17 und ein Grafik-Stack, der nicht mehr an OpenGL hängt. Für Widget-Anwendungen ist der Umstieg weitgehend mechanisch. Für Qt Quick auf Embedded-Hardware steckt die Arbeit in Shadern, eigenem OpenGL-Code und einigen neu geschriebenen Modulen – und diese Arbeit lässt sich vorab benennen, statt sie mittendrin zu entdecken. Je länger ein Produkt lebt, desto klarer fällt die Antwort auf „Qt 5 oder Qt 6?“ aus. Wenn Sie sie für Ihre Codebasis beantwortet haben möchten, sprechen Sie uns an.