Login
Newsletter
Werbung

Fr, 20. April 2012, 12:20

Software::Entwicklung

Kontroverse um Qt 5

Lars Knoll hat in einem Artikel klargestellt, dass die bisherigen C++-Schnittstellen auch in Version 5 der Qt-Bibliothek erhalten bleiben. Nach Ansicht einiger Kommentatoren geht er jedoch auf die eigentliche Kritik nicht ein.

Die klassischen Oberflächenelemente der Klassenbibliothek Qt sind von QWidget abgeleitet. In Qt 4.7 kam Qt Quick hinzu, das bevorzugt über die deklarative Sprache QML definiert wird, aber auch mittels QGraphicsView von C++ aus nutzbar ist. In Qt 5, das momentan in Entwicklung ist, soll eine erneuerte Version von Qt Quick zum Einsatz kommen, die auf Scenegraph aufsetzt und zwingend OpenGL voraussetzt. Nachdem die Qt-Entwickler bereits verkündet hatten, dass in Qt 5 alle Oberflächen mit QML entwickelt werden sollen, bemüht sich Lars Knoll nun klarzustellen, dass es weiter möglich sein wird, mit den QWidgets zu entwickeln, und dass die neue Version so weit wie möglich Quellcode-kompatibel zu Qt 4 sein wird.

QWidget ist nach seiner Darstellung abgeschlossen, was bedeutet, dass keine aktive Entwicklung mehr stattfindet. Fehler werden allerdings korrigiert. Außerdem ist das Projekt für jegliche externen Entwickler und neue Ideen offen, lediglich von Seiten Nokias findet zur Zeit keine Aktivität mehr an QWidget statt.

Nokia ist offenbar zur Zeit nur noch an Qt Quick interessiert. Ein Grund dafür ist, dass QWidget nicht dafür geeignet war, neu aufgekommene UI-Konzepte zu verwirklichen, wie sie in Smartphones und Tablet-Rechnern, zunehmend aber auch in Desktop-Anwendungen, zu finden sind. Dafür entstand Qt Quick, das nun parallel zu QWidget existiert.

Trotz QML und JavaScript bleibt C++ die Hauptprogrammiersprache von Qt, so Knoll. Qt Quick und QML seien ja lediglich zusätzliche Optionen. Zusammenfassend könne man mit Qt 5 genauso entwickeln wie mit Qt 4. Aber um auch in Zukunft eine bedeutende Rolle zu spielen, war es nötig, Qt Quick zu schaffen.

Verschiedene Kommentatoren werfen Knoll vor, die Kritikpunkte völlig zu verfehlen. Ein Problem sehen sie in der Anforderung, dass Qt Quick OpenGL benötigt. Diverse industrielle und eingebettete Systeme seien aber nicht OpenGL-fähig. Es existieren zwar reine Software-Implementierungen von OpenGL, aber diese sind mutmaßlich zu langsam. Ein anderer Punkt ist, dass das neue Qt Quick nur mit QML nutzbar ist - ein C++-API existiert noch nicht, und Nokia zeigt kein Interesse daran, eines zu implementieren. Die Nokia-Entwickler beharren darauf, dass es mit QML so viel einfacher sei, die Oberfläche zu definieren. Die Kritiker weisen auf den Overhead und die Notwendigkeit, weitere Programmiersprachen zu lernen, hin. Sie sind zahlende Kunden von Qt, die teils sehr große Projekte betreuen und eigene GUI-Klassen entwickelt haben. Sie haben prinzipiell nichts gegen Qt Quick, sie bemängeln lediglich, dass es kein C++-API gibt, und fragen sich, wie sie ihre eigenen GUI-Klassen integrieren können.

Desweiteren empfinden es manche Kommentatoren als paradox, dass Qt stärker als je zuvor auf Mobilgeräte zielt, aber die beiden wichtigsten Plattformen, Android und iOS, nicht unterstützt. Dafür gibt es jedoch technische Gründe, so unterstützt Android erst seit kurzem native C++-Anwendungen, und iOS ist ein schwieriges Ziel für die Portierung. Dennoch sind Portierungen sowohl für Android als auch für iOS in Arbeit. Letztlich wird aber die Gemeinschaft diese Arbeit leisten müssen, da Nokia selbst wohl nicht interessiert ist. Da aber Qt nun ein offenes Projekt ist, ist die Portierung auch im Rahmen des Projekts selbst möglich.

Werbung
Pro-Linux
Pro-Linux @Facebook
Neue Nachrichten
Werbung