Ausblick auf Gtk und Gnome 2.0 - Teil 1

Bereits vor etwa einem Jahr sollte sie eigentlich fertig sein, doch noch immer müssen wir uns gedulden, bis die Version 2.0 des Widget-Sets Gtk+ zu bewundern sein wird. Die Vorabversionen sind jedoch bereits erhältlich; das gibt die Gelegenheit, zuerst einen Blick auf neue Konzepte und Erweiterungen der Bibliotheken zu werfen, um sodann ganz praktisch mit Software im Betastadium zu experimentieren.

Der erste Teil dieses zweiteiligen Artikels soll die Theorie beleuchten, die Roadmap und ihre Termine erläutern und prüfen, was sich an den Fundamenten von Gnome ändern soll. Im Vordergrund steht dabei Gtk+. Im Anschluss daran werden die Viciuos Build Scripts vorgestellt. Das ist eine Handvoll Skripte, die auch bei einer bestehenden Gnome-Installation parallel die aktuelle Vorabversion von Gnome 2.0 installieren soll, ohne dass es zwischen beiden zu Konflikten kommt.

Der zweite Teil im nächsten Heft wird etwas Code-lastiger sein: mit Programmierbeispielen des bisherigen und des neuen Widget-Sets und der Gnome-Bibliotheken sowie mit Hinweisen zur Portierung oder zum Updaten von Programmen. Zunächst aber starten wir mit den Fundamenten von Gnome und Gtk+.

Ganz tief unten

Wer Gtk+ 1.2 kennt, dem wird zuerst die Fülle neuer Begriffe auffallen. Neben den üblichen Dingen wie GLib, Gtk+ und GDK kommen GObject, ATK und Pango dazu, schließlich noch GdkPixbuf, das treuen Lesern jedoch bereits aus Ausgabe 10/00 bekannt ist.

Die GLib war und ist eine Bibliothek, die dem C-Programmierer das Leben erleichtern und Plattformunabhängigkeit der Programme garantieren soll. Jetzt kommen einige neue Datentypen hinzu, die den geläufigen »integer«, »double«, »char« und so weiter zwar entsprechen, aber auf jeder Plattform garantiert gleich lang sind. Ein »gint32« ist also immer 32 Bit lang, sowohl auf einer 32-Bit-Plattform wie i386 oder einem IA64. Auf diese Weise kann man sich beispielsweise bei Bitfeldern andere Herangehensweisen erlauben.

Hinzu gesellen sich Datentypen wie einfach und doppelt verkettete Listen, Hashtabellen, binäre und n-näre Bäume, Arrays und einige andere, die sich in reinem C nur schwierig handhaben lassen, mit der GLib aber recht komfortabel zu benutzen sind. Insbesondere muss man sich um die genauen Details der Speicherallozierung nicht kümmern; Speicher wird grundsätzlich durch das Anlegen eines Objekts durch seinen Konstruktor mit der Endung »_new« alloziert und durch eine Methode, die auf »_free« endet, wieder freigegeben.

Wer sich jetzt fragt, was Objekte mit C zu schaffen haben, muss sich noch etwas gedulden, davon ist etwas später die Rede. Objekte werden aber auch Schwerpunkt im zweiten Teil sein. Neben diesen grundlegenden Erweiterungen bringt die GLib noch eine Menge zusätzlicher nützlicher Werkzeuge mit. Dazu gehören eine Thread-Implementation, ein simpler XML-Parser, Handhabung von Ein- und Ausgabekanälen, ein Plug-in-System, ein lexikalischer Scanner, Globbing von Dateinamen und noch vieles mehr.

Das alles funktioniert plattformunabhängig, also immer mit dem gleichen Interface, ohne dass der Programmierer auf die Besonderheiten des momentanen Systems Rücksicht nehmen müsste. Wer schon einmal Software von Linux nach Windows portieren durfte, wird die Zeitersparnis zu schätzen wissen, die sich damit zumindest theoretisch ergibt.

Objekte in C - kein Widerspruch

C ist keine objektorientierte Sprache. Daher sind viele Leute verwundert, wenn Sie von Objekten in Gtk+ oder schon in der GLib hören. Objektorientierte Programmierung (OOP) bezeichnet im Wesentlichen eine Art und Weise, den Programmablauf (die Methoden) zusammen mit den zugehörigen Daten (den Eigenschaften) zu organisieren.

Wesentliche Merkmale dieser Verbindungen aus Methoden und Eigenschaften sind Kapselung (Verbergen der Eigenschaften nach außen und Zugang zu ihnen nur über die Methoden), Vererbung (Ableiten neuer Objekttypen von anderen Objekten, wobei deren Methoden und Eigenschaften übernommen werden) und Polymorhpie (Erweiterung und Veränderung übernommener Methoden und Eigenschaften).

Dieses Organisationsprinzip wird häufig mit der Notation einer Programmiersprache verwechselt. Wenn es also in einer Sprache - wie in C - kein Schlüsselwort mit dem Namen »class« gibt, um eine Klasse zu definieren (Objekte sind immer eine Instanz einer bestimmten Klasse), dann wird diese Sprache als nicht objektorientiert angesehen. Doch auch die Notation von C kann durchaus für das Einführen einer objektorientierten Arbeitsweise eingesetzt werden. Die Entwickler haben die vorher bereits vorhandene OO-Arbeitsweise von GLib und Gtk+ noch einmal aufgebohrt und eine neue Basisklasse eingeführt, das so genannte GObject.

Zuvor war das grundlegende Objekt von Gtk+ das GtkObject. Es ist nun von Gtk+ eine Schicht tiefer in die Bibliothek GLib gewandert und in GObject umbenannt worden. Von dieser Klasse sind alle anderen Klassen in GLib, Gtk+ und so weiter direkt oder indirekt abgeleitet. Sei es nun ein GString oder eine Hashtabelle, ein Text-Widget oder ein Farbwahldialog: Alles ist ein GObject. Die Lebensdauer solcher Objekte ist über Referenzzähler geregelt. Jedes Objekt besitzt eine Anzahl von Referenzen, bei seiner Erschaffung mindestens eine. Erreicht diese Zahl den Wert null, wird das Objekt verworfen, da es nicht mehr referenziert wird.

Durch die Verlagerung des Basisobjekts von Gtk+ in die GLib ist es jetzt möglich geworden, das Objektsystem auch in Anwendungen zu benutzen, die keine grafische Oberfläche verwenden. Auf diese Weise wird das Programmieren mit der GLib von der Notation her zu einer vollständig objektorientierten Angelegenheit.

Abbildung 1: Die Vicious Build Scripts haben ihre Schuldigkeit getan.

Abbildung 2: Das Interface für die Gtk+-2.0 Demo.