Eine der Änderungen in GTK+-3.2: Der Dateiauswahldialog zeigt beim Öffnen nun von Haus aus eine Liste der zuletzt benutzten Dateien da - und beim Speichern die aktuell verwendeten Verzeichnisse.

Screenshot: Andreas Proschofsky

Wenn sich die EntwicklerInnen des GNOME-Projekts zu ihrer jährlichen Desktop-Konferenz versammeln, geht es nicht nur darum Bilanz über das vergangene Jahr zu ziehen und bereits fertig entwickelte Programme zu präsentieren, ab und an wirft man auch mal noch recht rohe Ideen in den Raum, um sie zur Diskussion zur stellen.

Spekulativ

So im Falle von GTK+4: Im Rahmen des derzeit in Berlin abgehaltenen Desktop Summit präsentierten die Red-Hat-Entwickler Matthias Clasen - der dort auch die GNOME-Entwicklungsgruppe leitet - und Benjamin Otte ihre Überlegungen zu einer potentiellen nächsten Generation des Toolkits.

GTK+ 3.2

Zunächst warf man aber einmal einen Blick auf aktuelle Entwicklungen, immerhin hat man erst vor nicht all zu langer Zeit mit GTK+3 einen großen API-Bruch durchgeführt. Als nächste Release steht nun GTK+ 3.2 an, das wieder einige wichtige Verbesserungen mit sich bringt. Dazu zählen etwa zwei experimentelle neue Backends, eines für den X-Server-Ersatz Wayland sowie ein HTML5-Backend namens Broadway, mit dem GTK+-Programme direkt im Browser - und auch von einem anderen Rechner aus - dargestellt werden können.

Vermischte Neuigkeiten

Darüber hinaus hat man sich im aktuellen Entwicklungszyklus weiteren Verbesserungen am Dateiauswahldialog gewidmet und das mit GTK+ 3.0 begonnene CSS-Theming erheblich in seinen Möglichkeiten erweitert. Auch Performance war wieder einmal ein Entwicklungsfokus, so dass die kommende Release einige der Probleme von GTK+ 3.0 in diesem Bereich wett machen soll.

Zufriedenheit

Alles in Allem ist man mit der GTK+3-Serie bislang sehr zufrieden, wie die beiden Entwickler betonen, man sei sogar positiv überrascht, wie wenige Probleme - nicht zuletzt in Hinblick auf die Stabilität - durch den Generationswechsel bei dem Toolkit ausgelöst wurden. Zudem gebe es noch jede Menge Möglichkeiten, die aktuelle Architektur zu erweitern und zu verbessern.

Defizite

Warum denkt man dann trotzdem schon wieder über größere Veränderungen nach? Die Motivation für solche Überlegungen stammen indirekt aus den Erfahrungen mit dem aktuellen Wechsel, und den damit klar gewordenen, grundlegenden Defiziten der jetzigen Architektur. Für Animationen, Effekte und Transformationen müsse man bisher externe Bibliotheken heranziehen, was die Situation für EntwicklerInnen erheblich schwieriger mache. So wäre die Hauptmotivation für ein GTK+4 denn auch die Entwicklung von GNOME-Anwendungen zu vereinfachen - und so auch zu beschleunigen.

Clutter

Auch wenn in dieser Hinsicht derzeit noch alles offen ist, hat man zumindest schon einmal einen vagen Vorschlag, wie dies aussehen könnte. So denkt man darüber nach die von Intel entwickelte - und unter anderem als Basis für die GNOME Shell genutzte - 3D-Bibliothek Clutter direkt in das Toolkit zu integrieren. Natürlich gebe es bis dahin noch einige Details zu klären und diverse technische Probleme zu lösen - prinzipielles Interesse an einem solchen Zusammengehen wurde aber zumindest auch schon von den anwesenden Clutter-Entwicklern signalisiert.

Multi-Plattform adieu?

Zugleich stellt man aber auch andere bisherige Eckpunkte von GTK+ zur Disposition. So brüste man sich bisher damit ein Multi-Plattform-Toolkit zu sein, in der Realität zeige sich aber, dass der Windows und Mac-Support alles andere als optimal seien. Wolle man diesen weiter beibehalten würde es zusätzlicher EntwicklerInnen bedürfen. Das Kern-Team rund um GTK+ sei jetzt schon vollkommen ausgelastet - und verwende noch dazu selbst ausschließlich Linux.

Offene Fragen

Wann solch ein GTK+4 dann kommen könnte, ist also noch vollkommen offen, in den nächsten Wochen und Monaten will man aber zumindest die weiteren Pläne umreißen. Zudem bleibt natürlich die Frage, welche solch ein erneuter Generationswechsel auf den GNOME-Desktop haben würde, und ob man dort dann im Versionsnummernreigen mitziehen würde. (Andreas Proschofsky, derStandard.at, 07.08.11)