C++-Framework: Was sich mit Qt 5 ändert
Die jüngere Geschichte des Cross-Plattform-Frameworks Qt liest sich wie eine Mischung aus schlechtem Thriller und Lehrbuch über Managementfehler. Die komplette Übernahme des Produkts durch Digia und die Veröffentlichung von Qt 5 kurz vor Weihnachten beendeten dann das Trauerspiel. Die umfangreichen Änderungen entfalten auf Entwickler eine geradezu magische Anziehungskraft.
- Tam Hanna
Die jüngere Geschichte des Cross-Plattform-Frameworks Qt liest sich wie eine Mischung aus schlechtem Thriller und Lehrbuch über Managementfehler. Die komplette Übernahme des Produkts durch das Beratungsunternehmen Digia und die Veröffentlichung von Qt 5 kurz vor Weihnachten beendeten das Trauerspiel – die umfangreichen Änderungen entfalten auf Entwickler eine geradezu magische Anziehungskraft.
Qt 4 erschien schon 2005. Damals waren Handcomputer teure Spielzeuge für VIPs und Technikfreaks – die Entwickler von Applikationen für diese Geräte waren hoch spezialisierte Informatiker, die sich nur damit beschäftigten. Geräte wie Palms Centro und das iPhone verschoben den Fokus. Plötzlich waren Smartphones angesagt, die Werbeindustrie entdeckte die Produkte als Trägerplattform. Dadurch veränderten sich die Ansprüche an Entwickler: "Early Adopters" forderten Funktionen, die "neu angeworbenen" Anwender waren mit schickem Design und primitiver Bedienung zufrieden. Ein einheitlicher Look und die effiziente Ausnutzung des Bildschirmplatzes sind unwichtig – stattdessen legt die neue Nutzerschicht Wert auf Effekte, aufwendige Hintergrundbilder und schickes Design.
Die Hardwareindustrie reagierte auf diese Änderungen. Heutige Handys enthalten Grafikprozessoren, die von der Leistung her den vor fünf bis zehn Jahren in Workstations eingesetzten Chips entsprechen. Auch auf Seiten der Hersteller fand ein Umdenkprozess statt. War das Fertigen von Handhelds früher die Aufgabe einiger darauf spezialisierter Anbieter, animierte die gesteigerte Breite des Markts neue Teilnehmer. Da diese auf den Sperreffekt einer eigenen Plattform setzen wollten, entstanden im Laufe der Zeit zunehmend mehr Betriebssysteme.
Qt war für diese "neue Welt" denkbar schlecht gerüstet. QWidgets integrierten sich eng in die GUI-Stacks der zugrunde liegenden Plattformen, was das Erstellen einer neuen Portierung ungemein erschwerte. Außerdem waren die Widgets den neuen Anforderungen nicht gewachsen: Sie wollten Daten möglichst effizient darstellen. Das Verschwenden von Bildschirmplatz war nach der damaligen Design-Philosophie ein Unding.
Doch damit nicht genug – den neuen Eigentümer Nokia bedachte die Community aufgrund seiner sonstigen Schwerpunkte (Symbian und MeeGo) mit Misstrauen. Deshalb waren Veränderungen angebracht. In einem am 19. Mai 2011 veröffentlichten Dokument versprach der Qt-Chefentwickler umfangreiche Änderungen für die nächste Version des Frameworks. Er legte die folgenden Ziele fest:
- neuer Grafik-Stack
- leichtere Portierbarkeit
- einfacher Code einreichen können
Abstraktion im Fokus
Trolltech lebte ausschließlich vom Verkauf kommerzieller Lizenzen des Frameworks. Darum passte das Unternehmen Qt an viele kommerzielle Unix-Systeme an – wer für sein Betriebssystem Lizenzgebühren bezahlt, zahlt wahrscheinlich gerne für die Entwicklungsumgebung.
Da die GUI-Stacks der verschiedenen Plattformen teilweise inkompatibel waren, führte man in Qt for Embedded Linux das QWS (Qt Windowing System) ein. Da damalige Embedded-Prozessoren keine fortgeschrittenen Grafikprozessoren enthielten, war die Unterstützung von OpenGL nicht vorgesehen (und ließ sich auch nicht ohne weiteres nachrüsten).
Im Laufe der Zeit kamen einige Entwickler auf die Idee, die Abhängigkeit vom Host-Betriebssystem auch am Desktop und im Mobilbereich durch das Einschieben einer Abstraktionsschicht (Qt Platform Abstraction)zu beheben. Diese würde als Fenstermanager agieren und die Steuerelemente darstellen – das Host-Betriebssystem ist nur mehr für das Einsammeln von Eingaben und das Ausgeben der berechneten Bitmaps verantwortlich.
Bodgan Vatra nutzte die Technik, um in geringer Zeit einen Port für Android bereitzustellen ("Necessitas"). Nach dem Beweis der Praxistauglichkeit entdeckte das Qt-Team, dass die Abstraktion auch zu einer wesentlichen Vereinfachung der Codebasis führt. Der Endeffekt dieser Überlegungen ist, dass das sogenannte Lighthouse in allen Portierungen von Qt 5 zum Einsatz kommt. Der frühere plattformspezifische Code fällt damit weg.
Aufgrund der angesprochenen zunehmend breiteren Verfügbarkeit von OpenGL beschloss das Qt-Team außerdem, OpenGL 2.0 (ES oder Desktop) vorauszusetzen. Der Sinn hinter dieser Einschränkung ist es, die Entwickler vom Zwang zur Berücksichtigung von Nicht-OpenGL-fähiger Hardware zu befreien. Wenn OpenGL als Basis gilt, wird der Standard auch voll ausgereizt.
Entwickler bemerken diese Änderung, da die bekannten Q_WS-Makros nicht mehr belebt werden. Das führt bei der Kompilierung des Programms meist nicht zu Problemen, legt es allerdings zur Laufzeit (im Rahmen der hoffentlich erfolgenden Akzeptanztests) flach:
#ifdef Q_WS_WIN
// Windows-API aufrufen
#endif
Der Grund dafür liegt darin, dass die plattformspezifischen Makros in Qt 5 mit der Zeichenkombination Q_OS beginnen. Wer in seinem Programm auf Q_WS setzt, bekommt keinen Compiler-Fehler. Da die Makros aber undefiniert sind, wird der plattformspezifische Code nicht ausgeführt. Korrekt sähe das Snippet also so aus:
#ifdef Q_OS_WIN
// Windows-API aufrufen
#endif
