Die Versionen 2.0 des Widget-Sets Gtk+ und von Gnome nehmen Konturen an. Zwar lässt die offizielle Freigabe noch auf sich warten, aber schon in der Vorabversion zeigt sich, wohin die Reise geht.

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.

Schleifchen binden

Gtk+ ist ein ereignisbasiertes Widget- Set; die einzelnen Widgets der grafischen Oberfläche werden mit Ereignissen assoziiert und diesen Ereignissen dann Funktionen zugewiesen, die bei Eintritt der Ereignisse aufgerufen werden. Diese Funktionen heißen Callbacks.

Das Warten auf Ereignisse ist dabei durch das Starten einer Schleife realisiert, bei deren Ablauf auf Ereignisse gewartet wird.

Diese Schleife ist nicht Gtk+-spezifisch, sondern ebenfalls in der GLib implementiert. So ist auch ereignisbasiertes Programmieren ohne Nutzung der grafischen Oberfläche möglich. Auch Dateideskriptoren und Sockets können nämlich als Quellen für Ereignisse dienen. Als Anwendungsbeispiel wäre etwa ein Netzwerkserver (oder auch ein Client) für Open Nap denkbar; wann immer etwas auf dem Socket passiert, führt das zum Aufruf bestimmter Funktionen. Durch den plattformunabhängigen Ansatz ist es dabei irrelevant, ob man sich beispielsweise unter Windows oder Linux befindet; die Handhabung mit GLib-Code bleibt gleich.

Diese Schleifen sind zudem auch in Threads behandelbar. Zwar kann jeder Thread nur seine eigene Menge von Quellen haben, aber diese Menge von Quellen ist auch aus anderen Threads heraus manipulierbar. Darüber hinaus sind über die Klasse »GSource« eigene neue Quellen für Ereignisse definierbar. Außerdem können natürlich immer noch einzelne Durchläufe der Schleife von Hand ausgelöst werden.

Jetzt wird’s grafisch

Die Dokumentation von Gtk+ unter[1] ist im besten Falle unvollständig zu nennen. Aber einige gravierende Änderungen haben die Widgets durchmachen müssen; vieles davon ist weiter unten zu erkennen, wo einige Screenshots aus der Demo-Anwendung einer Gnome-2.0-Installation gezeigt werden.

Bis Version 2.0 verließ sich Gnome beim Laden von Bildern und deren Manipulation auf die Bibliothek ImLib. Deren Möglichkeiten gingen den Gnome-Entwicklern aber nicht weit genug, so dass sie eine eigene Bibliothek namens GdkPixbuf entwickelten. Vielfach wurde moniert, dass sie nicht auf die ImLib2 warteten, die von Grund auf neu geschrieben ist. Die folgenden Vergleiche sind also immer in Relation zur alten ImLib zu sehen, nicht zur ImLib2.

Neben dem nicht vorhandenen Alpha-Blending in der ImLib (das in der ImLib2 natürlich hinzugekommen ist) bemängelte man vor allen Dingen das Speichermanagement. GdkPixbuf 2.0 ist voll in das Objektsystem der GLib eingebunden, daher werden Objekte ebenfalls über Referenzzähler gesteuert. Außerdem ist GdkPixbuf in der Lage, Bilder nur teilweise zu rendern, was bei der Darstellung in einem GdkDrawable, das mit Scrollbars in einem Fenster zu sehen ist, zu erheblichen Performancegewinnen führen soll.

Die Pixelpuffer-Bibliothek wird in Zukunft ihre Eigenständigkeit verlieren und ein Bestandteil von Gtk+ werden. So sind ihre Fähigkeiten auch dann nutzbar, wenn man sich nicht von den Gnome-Bibliotheken abhängig machen möchte.

Abbildung 3: GdkPixbuf im Einsatz.

Abbildung 4: Eine GtkColorSelection.

Kommunikationsschicht GDK

GDK ist eine Zwischenschicht, die die Kommunikation zwischen Gtk+ und dem darunter liegenden System zur grafischen Darstellung übernimmt. In der Theorie ist es egal, ob man nun ein XFree86 oder die Windows-API unten drunter hat; um Gtk+ zu portieren reicht es eigentlich aus, GDK an die betreffende Plattform anzupassen. Auch GDK ist jetzt durch und durch auf GObject ausgerichtet. Es sei an dieser Stelle an ein frühes Zitat eines Gtk+-Entwicklers erinnert, das sinngemäß lautet: “Gtk2 will never ever flicker. Never.” Ein großer Teil des Aufwands, dieses Versprechen zu erfüllen, dürfte wohl in die Entwicklung entsprechender Fähigkeiten von GDK geflossen sein.

ATK macht Gtk behindertengerecht

So schön und gut Gnome auch sein mag, es hat doch einen gravierenden Nachteil: Ebenso wie der Rest des Computers – einschließlich Maus, Tastatur, Monitor und so weiter – ist es auf Benutzer mit gesunden Augen und Händen ausgelegt. Sobald jedoch eine blinde Person den Desktop benutzen möchte oder jemand ohne Hände versucht Eingaben zu tätigen, wird man sich bewusst, dass etwas im Argen liegt.

Unter dem Stichwort Accessibility fasst man alles zusammen, was darauf abzielt, solche Barrieren bei der Gestaltung von Ein- und Ausgabegeräten aus dem Weg zu räumen und zwei Ziele zu erreichen: behinderten Benutzern Zugang zu Computern oder Technik im Allgemeinen ermöglichen und außerdem den Programmierern die Möglichkeit eröffnen, von Behinderten bedienbare Applikationen zu schreiben.

Der Ansatz soll dabei sein, Softwarekomponenten bei Bedarf in das System aufnehmen zu können, die einen Behinderten beim Benutzen des Rechners unterstützen: Vorgelesene Texte, On-screen-Tastaturen, kopfmontierte Zeigewerkzeuge und ähnliche Geräte sollen sich nahtlos in das System einfügen können, ohne dass sich an der Umgebung selbst etwas ändern muss.

Einen weiteren interessanten Aspekt hat Accessibility – ich benutze das englische Wort weiter, da mir keine passende deutsche Übersetzung geläufig ist – bei der Verbreitung freier Software zu bieten. Neben der Tatsache, dass man sich offensichtlich eine größere Nutzerbasis schafft, wird auf diese Weise die Konformität mit diversen Gesetzen geschaffen, die für die Verwendung der Software in Ämtern und anderen Regierungsstellen vorgeschrieben ist. So gibt es beispielsweise in den USA den Federal Rehabilitation Act, dessen Sektion 508 vorschreibt, dass die betreffenden Lieferanten eben diese Accessibility in ihren Produkten vorhalten müssen.

Das Gnome Accessibility Project hat eine eigene Sektion[6] in der Gnome-Website, in der neben den theoretischen und technischen Papieren beispielsweise auch eine Einführung in verschiedene nationale Gesetze der genannten Art gegeben wird. Die Lektüre ist sehr erhellend, gerade wenn man der Meinung ist, dass es einen nicht betreffen würde.

Abb. 5: GtkDrawingArea.

Abbildung 6: Bilder in Gtk+; unten dynamischer Aufbau.

Pango international

Pango ist ein Framework für das Layout und das Rendern von internationalisiertem Text. Obwohl es sich bei dem Projekt um einen Abkömmling der Gtk+- und Gnome-Entwicklung handelt, ist es davon unabhängig und kann auch anderweitig genutzt werden.

Was macht man genau damit? Einer der großen Vorteile freier Software sind die besseren Möglichkeiten zur Internationalisierung und Lokalisierung, also für die Anpassung eines Programms an die Sprache und andere Standards eines bestimmten Landes, beispielsweise bei den Währungs- oder Zeitnotationen. Internationalisierung nennt man in diesem Zusammenhang die Vorbereitung eines Programms, um es für Lokalisierungen geeignet zu machen.

Eines der größten Probleme bei der Lokalisierung von Programmen sind Sprachen, die sich nicht von links nach rechts schreiben lassen, sondern in die entgegengesetzte Richtung; Arabisch und Hebräisch sind dabei besonders beliebte Kandidaten. Aber auch generell bringt die Darstellung anderer Zeichen als die in Europa und vielen anderen Ländern gebräuchlichen lateinischen Buchstaben Probleme. Wenn man zum Beispiel auch noch Dinge wie die Notation von Vokalen mit Punkten über Zeichen wie im Arabischen oder die Verschiebung von Vokalen im Wort in anderen Sprachen berücksichtigt, dann wird es wirklich kompliziert.

Pango soll das Rendern von Text vereinheitlichen und die Darstellung von Text auch in Gnome 2.0 übernehmen. Es ist Unicode-basiert und modular aufgebaut, die Darstellung einzelner Sprachen kann also auf Verlangen zusätzlich geladen werden. Dabei sind unterschiedliche Sprachen im gleichen Widget darstellbar, selbst die gegenläufige Schreibrichtung ist kein Hindernis. Die auf der Pango-Website[5] zu bewundernden Screenshots sind zwar schon etwas älter, aber immer noch recht interessant. Eine nette Demonstration der aktuellen Fähigkeiten von Pango gibt es außerdem weiter unten bei den Screenshots der Gtk+-2.0-Demo.

Abbildung 7: Interaktive Dialoge, hier mit GtkEntry.

Abbildung 8: Sock Icons – die neue Generation der Symbole.

Installation

Wer mit Gtk+ 2.0, Gnome 2.0 und den damit verbundenen Bibliotheken experimentieren möchte, dem werden gegenwärtig die Vicious Build Scripts an die Hand gegeben, mit denen sich eine Installation vornehmen lässt, ohne dabei ein bestehendes Gnome berühren zu müssen. Um die im Folgenden erläuterten Schritte nachvollziehen zu können, muss »wget« auf dem System installiert sein; als Shell werden Bash oder Zsh vorausgesetzt.

Die Skripte gibt es nicht als Paket, sondern nur vom Gnome-CVS-Server; dort liegen sie unter »vicious-build-scripts« als Modul vor. Zunächst ist ein Verzeichnis einzurichten, in das die Skripte kopiert werden sollen, zum Beispiel »/usr /src/gnome-2.0«. Unter

# export CVSROOT=:pserver: U
   anonymous@anoncvx.gnome.org U
   :/cvs/gnome
# cvs login
# cvs -z3 co vicious-build-scripts

ist die aktuelle Version zu finden. Auf die Frage nach dem Passwort beim Login genügt ein Druck auf die [Return]-Taste. Man erstellt sich nun ein »bin«-Verzeichnis in seinem Heimatverzeichnis und wechselt nach »vicious-build-scripts/«. Mit einem

# make install

lassen sich die Installationsskripte dann nach »~/bin« kopieren.

Editier mich!

In der Datei »~/bin/gnome-head« existiert die Variable »BASE«, die das Ziel für die Installation von Gnome 2.0 angibt. Standard ist hier »/gnome«; zu empfehlen ist die Umbenennung in »/usr/local/gnome-2.0«.

Wenn nun noch der Inhalt der Datei »gnome-head« in die neue Umgebung aufgenommen ist, was durch die Eingabe von

# source gnome-head

geschieht, kann man das Skript »bootstrap.sh« laufen lassen, das die aktuellen Quellen aus dem CVS von Gnome holt. Falls der in den Skripten angegebene Server für diverse Pakete [www.ibiblio.org] nicht erreichbar ist, lässt sich in die editierte Datei auch ein anderer Server eintragen, beispielsweise [ftp://ftp.cs.tu-berlin.de]. Auch sollten die Umgebungsvariablen »CFLAGS«, »LDFLAGS«, »CPPFLAGS« und »CXXFLAGS« auf leere Werte gesetzt sein, damit die neuen Quellen nicht mit schon installierten Bibliotheken oder Header-Dateien durcheinander kommen.

Der Bootstrap-Prozess installiert aktuelle Versionen von »automake«, »autoconf«, »gettext« und »libtool« sowie »pkgconfig« und »audiofile«.

Nachdem diese Vorbereitungen beendet sind, geht es mit dem Start von »rebuild.sh« ans Eingemachte. Nun heißt es, sich zurücklehnen und der Dinge harren, die da kommen. In der Zwischenzeit kann man sich ja getrost um wichtige Dinge kümmern; da waren beispielsweise doch die Pläne, zu Weihnachten noch diverse Abos für das Linux-Magazin zu verschenken – da brach das Skript in einem Linkerprozess bei der »glib« ab.

Ich fügte das Verzeichnis »/usr/local /gnome2.0/head/INSTALL/lib« den Einträgen in der Datei »/etc/ld.so.conf« hinzu, was dieses Problem beseitigte. Ein weiteres Problem warf Pango allerdings danach auf, als die für »pkg-config« notwendige Datei »pangoft2.pc« nicht zu finden war; ich musste sie vom CVS-Verzeichnis von Pango per Hand nach »/usr/local/gnome-2.0/head/INSTALL/lib/pkg-config« kopieren.

Wenn der Kompilierungsprozess abbricht, sollte man die Umgebungsvariable »STARTMODULE« auf jenes Modul setzen, bei dessen Behandlung soeben der Abbruch erfolgte, damit der ganze Reigen nicht wieder von vorne beginnt.

Abbildung 9: Editierbare Zellen in Listen und Bäumen.

Abbildung 10: Listen und Bäume können nicht nur Text enthalten. Die Checkboxes in der ersten Spalte repräsentieren den Typ »G_TYPE_BOOLEAN«.

Genesis – ein Erfahrungsbericht

Nach einer ganzen Weile war es dann so weit: Ich erhielt die wunderbare Meldung, die man in Abbildung 1 im Terminalfenster sehen kann: All done! Das war so schön, dass ich es kaum glauben konnte. Umso enttäuschter war ich allerdings, als gar kein komplettes System mit neuem Panel zu sehen war, sondern nur ein Terminalfenster vor meinen Augen erschien.

Eigentlich hätte ich gewarnt sein sollen, aber dennoch, ich wollte schon etwas zu sehen bekommen. Glücklicherweise war im neuen Installationsverzeichnis ein Binary mit dem Namen »gtk-demo« zu finden – und das hielt dann auch, was es versprach. Das Demo-Programm, das auch in Abbildung 2 zu sehen ist, hält einige Dinge bereit, nach denen man sich als Gtk+-Programmierer die Finger lecken wird.

In Abbildung 3 sind erst einmal nur ein paar Icons zu erkennen. Es handelt sich aber um eine Animation, in der einige Stock Icons, die mit Transparenz in den Hintergrund hinein und wieder heraus rotieren. Eine schöne Demonstration dessen, was mit GdkPixbuf möglich ist – oder sein wird, wenn es fester Bestandteil von Gtk+ ist. In Abbildung 4 ist eine Farbauswahl zu erkennen, in Gtk+-Begriffen also eine GtkColorSelection. Von dem bisher benutzten Farbkreis ist Gtk+ abgekommen. Stattdessen gibt es ein Farbdreieck.

Die Drawing Area, wie sie in Abbildung 5 zu sehen ist, verfügt nicht nur über einen Pufferbereich, in den gemalt werden kann und der sich anschließend darstellen lässt, indem man das Signal »expose_event« von Hand absendet. Die Area reagiert auch auf Mausereignisse wie das Klicken und Bewegungen, so dass sich einfache Mal-Aktionen direkt im Widget ausführen lassen.

Mit Bildern geht es dann auch in Abbildung 6 weiter. Hier können wir oben ein statisches Bild und in der Mitte auch ein animiertes sehen. Besonders interessant ist der untere Teil, in dem gerade ein Bild geladen wird, während die Applikation weiterläuft. Dies Verhalten ist ebenfalls eine der Fähigkeiten, die GdkPixbuf bereithält.

Dialoge waren bislang weitgehend statisch und unterschieden sich nur durch die Anzahl, Art und Anordnung der Buttons, mit denen der Benutzer weitergeleitet worden ist. Mit der Möglichkeit interaktiver Dialoge können aber auch andere Elemente in Dialoge eingebettet werden, wie es in Abbildung 7 beispielsweise bei zwei Entries zu sehen ist, die in der Gtk+-2.0-Demo-Anwendung vor dem Starten des Dialogs mit Werten belegt werden können.

Während die Codebasis um-, neu- und wieder geschrieben wurde, blieb genug Zeit, um das Aussehen von Widgets anzupassen. Die meisten Unterschiede werden nur bei ganz genauem Hinsehen und bei bestehender Möglichkeit zum Vergleich auffallen. Deutlich erkennbar werden Veränderungen im Aussehen allerdings bei den neuen Stock Icons. Das ist eine Sammlung neuer Symbole für alle möglichen Anwendungsfälle; vom »OK«-Button bis zum Symbol für einen »Suchen und Ersetzen«-Eintrag in einem Menü ist alles vorhanden, was das Entwicklerherz begehrt.

Wer mal neugierig im Verzeichnis »/usr /local/gnome-2.0/head/INSTALL/share/ pixmaps« nachschaut, wird jedoch bedauernd feststellen, dass sich die Gnome-Icons (noch?) nicht von denen unterscheiden, die man bereits von Version 1.4 her kennt.

Eines der Sorgenkinder von Gtk+ 1.2 waren die Listen- und Baumwidgets, die zwar einiges konnten, aber dennoch nicht wirklich zu all dem fähig waren, was man gerne gesehen hätte. Diese Widgets haben eine gründliche Umstrukturierung erfahren. Zuerst einmal gibt es nur noch den Baum. Listen sind Sonderfälle von Bäumen, die lediglich eine einzige Ebene haben. Auf diese Weise müssen ähnliche Fähigkeiten nicht doppelt implementiert werden.

Außerdem funktionieren die Bäume jetzt nach dem MVC-Prinzip (Model, View, Controller). Demnach gibt es eine Darstellung der Daten im Speicher, die als Modell bezeichnet wird. Wer Daten darstellen möchte, wählt eine bestimmte Ansicht (View) auf sie. Mit Hilfe verschiedener Ansichten kann man dieselben Daten auf mehrere Weisen aufbereiten, filtern und darstellen. Der Controller dient darüber hinaus dem Verändern der Daten. Er kann sowohl Bestandteil einer View – etwa wenn sich Zellen einer Tabelle direkt verändern lassen -, aber auch komplett unabhängig von jeder Darstellung sein.

Das neue Baumwidget findet in einer gnomifizierten Version bisher in der Bibliothek »gal« Verwendung, die beispielsweise in dem Mail-Client Evolution bereits für alle tabellarischen Darstellungen benutzt wird.

In Abbildung 9 ist zu sehen, wie der Inhalt einer Tabellenzelle in einem Einkaufszettel direkt verändert wird. In Abbildung 10 besteht der Tabelleninhalt nicht nur aus Text. Zellen werden grundsätzlich über GLib-Typen wie »G_TYPE _STRING«, »G_TYPE_INT« und so weiter definiert. Die Check-Buttons in Spalten werden durch den Typen »G_TYPE_ BOOLEAN« erzeugt. In Abbildung 11 kann man verschiedene Werte für diese Check-Buttons erkennen: Die grauen Kästchen repräsentieren dabei »FALSE«, die mit dem Häkchen »TRUE« und die leeren weißen Kästchen sind mit einem »NULL« versehen.

Meinen ganz besonderen Favoriten habe ich mir als Highlight für den Schluss aufgehoben: das neue Text-Widget. In den beiden Abbildungen 12 und 13 ist eine Menge neuer Möglichkeiten auf einmal zu bestaunen: So gibt es wie beim neu-en Baum- und Listen-Widget nun einen MVC-Ansatz, der mehrere Ansichten auf ein und dasselbe Modell zeigt. Zu sehen ist das in den beiden Abbildungen an den oberen, kleineren Text-Widgets; es handelt sich dabei um verschiedene Ansichten auf denselben Inhalt.

Wort- und Zeilenumbrüche werden jetzt ohne den lästigen Pfeil am Ende einer Zeile bearbeitet und – wie man sehen kann – sind auch unterschiedlich formatierte Texte darstellbar.

Wer bereits von der Möglichkeit, Widgets in GtkText einzubetten, begeistert ist, wird über Abbildung 13 regelrecht staunen: Pango in Aktion, mit links und rechts ausgerichtetem Text verschiedener Sprachen im gleichen Widget. Ein zusätzliches Gimmick ist im Bild nicht erkennbar: Das kleine Diskettenmännchen ist animiert und winkt.

Abbildung 11: Unterbäume; Widgets.

Abbildung 12: Das neue GtkText.

Abbildung 13: Noch mehr Staunenswertes in GtkText.

Weiter mit Details und Code

Mancher wird behaupten, viele Einzelheiten schon einmal irgendwo anders gesehen zu haben, die sich als neue Features in Gtk+ 2.0 und Konsorten tummeln. Aber das Zusammenspiel so vieler neuer Konzepte als Unterbau für einen kompletten Desktop ist neuartig.

Um die Änderungen genauer ansehen zu können und dem theoretischen Ausflug etwas praktisches Futter zu geben, tauchen wir in der nächsten Ausgabe in die Tiefen des Quellcodes ab; die ersten Programmierbeispiele für Gtk+ 2.0 und dann auch Gnome 2.0 werden eine Weile für Beschäftigung sorgen und uns damit die Wartezeit bis zur ersten offiziellen Release verkürzen. Fröhliches Gnomen! (uwo)