QT ist nicht C++
« | 30 Dec 2018 | »Wäre QT ein richtiges C++ Framework, dann könnte ich ihm einiges abgewinnen. Doch wenn eine Bibliothek für eine Sprache immer Zusatztools benötigt um den geschrieben Code in etwas zu konvertieren, was der Compiler versteht, dann ist es etwas anderes und kein echtes C++.
Und QT ist eben ein solches “anderes” Framework.
Wie so oft in der Geschichte der Softwareentwicklung, kamen die Konzepte von QT einfach zu früh auf den Markt. Die Compiler der späten 90er waren nicht flexibel genug und boten nicht die nötigen Features um effizient und einfach das anzubieten, was QT realisieren wollte.
Und das war ein einheitliches Event-System für GUIs, genannt Signals and Slots.
Also meinten die Erfinder von QT:
Ach was, wir führen ein paar neue einfache Schlüsselwörter ein, und jagen diesen QT-Code dann noch mal durch einen speziellen Präprozessor, der daraus komplexen C++ Code generiert, der dann an den Compiler weitergereicht wird.
Doch mit dieser Strategie entfernt man sich vom Sprachstandard und bindet sich an nur jene Plattformen, die diese Präprozessor-Tools unterstützen. Da man “seinen eigenen” Standard hat, bedarf es an Anpassungen für jeden Compiler Hersteller, die dann leider nur für die wichtigen durchgeführt werden, und so verliert man einen der wichtigsten Aspekte von C++: nämlich Plattformunabhängigkeit.
Wenn es daher um die Wahl eines GUI Frameworks geht, muss ich - wenn möglich - QT immer im Vorhinein ausschließen, weil seine Anforderungen und seine Integration in eine Plattform bzw. in ein Entwicklungssystem immer mit Schwierigkeiten verbunden sind.
In einem vergangenem Firmenprojekt war QT die Basis für die GUI Entwicklung
und es ist keine Lüge, wenn ich behaupte, dass alleine das Setup der
Umgebung einen Tag benötigte.
Das lag natürlich auch an der mangelnden Dokumentation, aber auch am
Aufbau und den Abhängigkeiten von QT und seinen Komponenten.
Und so musste man immer erst Ausprobieren, welche Environment-Variable noch fehlte, damit zuerst alle Tools ihre Verzeichnisse finden und Mehrdeutigkeiten ausgemerzt werden konnten, um dann nach dem Kompilieren mehrere Bibliotheksabhängigkeiten manuell nachtragen zu können.
Wenn nach der Installation eines Frameworks (Dauer 15 Minuten) noch unzählige manuelle Schritte notwendig sind (Dauer 6 Stunden), bis man endlich ein größeres Projekt kompilieren kann, dann ist das Framework … naja, sagen wir mal ausbaufähig.
Unter Linux wird das Chaos um so größer, wenn man zwei Projekte mit
unterschiedlichen QT Versionen bearbeiten muss. Denn hier gibt es dann
gerne immer wieder Konflikte, weil eine Environment-Variable eben nur einmal
pro Session gesetzt werden kann.
Und wenn man zusätzlich noch das Pech hat, auf eine ältere QT Version wegen
einer Third-Party Komponente angewiesen zu sein, bleibt einem oft nur der
Weg über eine Virtualisierungslösung.
Man muss aber auch so fair sein und dazu sagen, dass mit dem Aufkommen von C++ sich niemand ernsthaft Gedanken über die GUI Entwicklung gemacht hat und selbst das boost Projekt bis heute keine vollständige Alternative zu QT anbietet.
wxWidgets und gtkmm stellen aber wegen ihres an den Standard angelehnten Aufbaus aus meiner Sicht einen besseren Ansatz für GUI Frameworks dar.
Das GATE Projekt baut vorerst unter Windows direkt auf der WINAPI und ansonsten auf GTK+ auf. QT und wxWidgets wären technisch unmöglich in diesem Projekt gewesen, da ihnen eine reine C Schnittstelle fehlt.