GTK+4: GNOME will Toolkit stark umbauen

24. Oktober 2010, 13:59
4 Postings

"Hackfest" verpasst GTK+3 letzten Feinschliff und neues Theming-System - Erst Schritte für GTK+4

Jahrelang hatte man sich beim GNOME-Projekt recht konservativ im Umgang mit dem eigenen Toolkit GTK+ gegeben, neue Funktionen standen immer unter der Prämisse die versprochene API/ABI-Stabilität nicht zu brechen. Eine Vorgabe, von der man mit GTK+3 abweichen will, die für Dezember geplante neue Generation der Software schmeißt eine ganze Reihe nicht mehr aktueller Programmierschnittstellen aus der Code-Basis.

Umbauten

Ein Unterfangen, das sich derzeit zu einer Art Befreiungsschlag des Projekts von alten Fesseln zu entwickeln scheint: In den letzten Monaten hat sich die Entwicklung deutlich intensiviert, zuletzt hat man etwa das gesamte Rendering-Framework umgebaut, nutzt hier nun in weiten Teilen direkt die 2D-Bibliothek Cairo - und kann so auch von deren Performance-Fortschritten direkt profitieren.

Hackfest

Nun geht man noch einige Schritte weiter: Im Rahmen eines "Hackfest" im spanischen La Coruna haben sich in den letzten Tagen die Kern-EntwicklerInnen des Toolkits versammelt, um die weitere Zukunft ihres Projekts zu planen - und auch gleich in Code zu verwandeln. Angesichts des aktuellen Schwungs beschränkte man sich dabei nicht auf ausstehende Umbauten und neue Funktionen für GTK+3, sondern diskutierte auch gleich wesentlich umfangreichere Änderungen, die in einem kommenden GTK+4 landen sollen.

GTK+4

So könnte die übernächste Generation der Software von konzeptionellen Änderungen gekennzeichnet sein, die unter anderem das Zusammenspiel mit der 3D-Bibliothek Clutter - die im GNOME-Umfeld derzeit immer breiteren Einsatz findet - vereinfachen soll. Zu den konkret anvisierten Änderungen gehört, dass man künftig nur mehr Top-Level-Fenster zulassen und "Windows-Less Scrolling" implementieren will, auch das Input-Handling soll umgebaut werden. Die Änderungen sollen zudem die Anpassung auf eine OpenGL-beschleunigte Ausgabe sowie die Schaffung eines Backends für den - potentiellen - X-Server Nachfolger Wayland erleichtern.

GLib4

Parallel zu GTK+4 soll es dann auch eine neue Generation der Glib-Bibliothek geben, bei der man nun ebenfalls mit der API/ABI-Kompatbilität brechen will - parallel zu GTK+3 hatte man auf diesen Schritt ja noch verzichtet. Unter den geplanten Änderungen finden sich Aufräumarbeiten an GObject sowie Verbesserungen am Mainloop - etwa in Form von Mikrosekunden-Genauigkeit.

GTK+3

Freilich muss man zuerst einmal GTK+3 fertigstellen, ein Unterfangen, bei dem man während des Hackfests allerdings erhebliche Fortschritte gemacht hat: So wurde das - im letzten Release-Zyklus kurzfristig zurückgezogene - GApplication-API - mit dem Anwendungen auf eine eindeutige Instanz festgelegt werden können - neu geschrieben, außerdem hat man mit GtkStyleContext ein neues Theming-API in Form gebracht. Dieses soll das Erstellen von Themes mit einer CSS-ähnlichen Syntax wesentlich erleichtern. Bereits als eine Art Vorbereitung für GTK+4 ist die Einführung einer "Paint Clock" zu verstehen, die Zeichenaufgaben zwischen GTK+ und Clutter synchron halten soll.

Ausblick

Angesichts dessen, dass die Pläne für GTK+4 noch ganz frisch sind, kann es nicht weiter verwundern, dass es aktuell noch keinen Zeitrahmen für dessen Veröffentlichung gibt. In Blog-Einträgen beschränkt man sich auf die Bemerkung, dass es wesentlich flotter gehen könnte, als bisher anvisiert. Im Vorfeld von GTK+3 hatte man über einen Major-Release-Zyklus von drei Jahren gesprochen, der neue Plan sollte also deutlich flotter implementiert werden - wenn alles gut geht. (apo, derStandard.at, 24.10.10)

Der WebStandard auf Facebook

Share if you care.