Überblick über die GNOME-Entwicklungsplattform -- Material zum Vortrag "Einführung in die GNOME-Programmierung"

Die G-Welt

GNOME-Programmierung spielt sich in einer Welt ab, die ich auf Grund des inflationären Vorkommens des Anfangsbuchstabens G in Programm-, Bibliotheks-, Klassen-, Typ- und Funktionsnamen als `G-Welt' bezeichnen möchte. Folgendes macht diese Welt aus:

All dies kann ein Programm noch verwenden, ohne ein GNOME-Programm zu sein. "Reine" GTK+-Anwendungen wie The GIMP halten sich in der G-Welt, aber nicht im GNOME-Land auf.

Die GNOME-Plattform als Bündel von Bibliotheken

GNOME stellt sich nicht als eine große, monolithische Bibliothek dar, die alle Klassen und Funktionen bereitstellt, die GNOME-Funktionalität ausmachen, sondern als ein ganzes Bündel einer (leider?) erstaunlich großen Zahl von Einzelbibliotheken, die jeweils einen bestimmten Zweck erfüllen. Nur einige davon exponieren jedoch für den Entwickler wichtige APIs; zu ihnen gehören:

Der Dokumentationszustand der meisten dieser Bibliotheken hat sich in letzter Zeit um einiges verbessert, lässt aber immer noch viel zu wünschen übrig. An dieser Stelle sei erwähnt, dass es mit DevHelp mittlerweile einen Hilfebrowser speziell für Entwickler gibt, der den Zugriff auf die Referenzdokumente der installierten Bibliotheken stark vereinfacht (siehe Abbildung).

Konfiguration mit GConf

Anwendungen haben es an sich, konfigurierbar zu sein. Dies bedeutet letztlich, dass irgendwo eine Reihe von Werten vorliegt, deren Beträge das Verhalten oder das Aussehen der Anwendung bestimmen.

Um dies zu realisieren, ginge man normalerweise etwa so vor:

Hieraus ergeben sich sofort einige Probleme. Wie erfährt beispielsweise die Anwendung, wenn ein Konfigurationswert geändert wurde? Welches Dateiformat wird verwendet, und wo landet die Datei? Was passiert, wenn die Konfigurationsdatei geändert wird, während die Anwendung läuft? Und heißt es nicht das Rad neu erfinden, diesen Mechanismus für jede Anwendung neu zu schreiben?

GConf löst die Probleme auf ziemlich elegante Art und Weise. Es gibt eine zentrale Konfigurationsdatenbank, die eine als Verzeichnisbaum gegliederte Hierarchie von typbehafteten Schlüsseln enthält, die Werte aufnehmen können. Sie tun nunmehr folgendes:

Dies führt dazu, dass jede Änderung an der Konfigurationsdatenbank, ganz gleich, wann und von wo sie erfolgt, sofort an die Anwendung durchgereicht wird (dies wird übrigens auch von den GNOME-Ergonomierichtlinien verlangt -- siehe unten). Die Kopplung zwischen der Stelle, an der die Einstellungen vorgenommen werden, und jener, an der sie wirken, erfolgt nur über die Datenbank, ohne anwendungsinterne Logik. Auch über die Speicherung der Schlüssel müssen Sie sich keine Gedanken mehr machen. Seiteneffekt des Ganzen ist, dass es einfach ist, die Anwendung über externe Werkzeuge zu konfigurieren, was besonders Systemadministratoren freut.

Ein solches externes Werkzeug wird bei GNOME schon mitgeliefert, nämlich der GConf-Editor (siehe Abbildung).

Dateizugriff mit GNOME-VFS

GNOME-VFS ist eine Bibliothek, die GNOME-Anwendungen ein virtuelles Dateisystem bereitstellt; daher auch der Namensteil `VFS' für `Virtual File System'.

Warum nun aber ein virtuelles Dateisystem benutzen und nicht einfach auf das native zugreifen? Neben dem allfälligen Rechtfertigungsgrund für Abstraktionsschichten, der Portabilität, geht es auch darum, den Begriff des Dateisystems zu erweitern -- mit GNOME-VFS können Sie nicht nur Inhalte auf einer lokalen Platte als Dateisystem ansprechen, sondern auf gleicher Weise auch den Inhalt einer Archivdatei oder den eines Web"=Servers auf der anderen Seite des Planeten.

Das Grundkonzept von GNOME-VFS steht auf zwei Säulen: Es werden URIen statt Dateinamen verwendet, um Dateien oder Verzeichnisse zu identifizieren, und die Funktionen sind transparent, das heißt, alle Zugriffe auf Dateien verwenden dieselbe URI-basierte API, unabhängig davon, wo die Dateien sich befinden und in welcher Art auf sie zugegriffen wird. Wenn Sie also Ihre Zugriffe über GNOME-VFS abwickeln, können Sie überall dort, wo Sie sonst Dateinamen akzeptieren würden, URIen akzeptieren und ihre Benutzer damit zum Beispiel Dateien, die irgendwo im Netz liegen, genauso zugänglich machen wie lokale, ohne Code für Netzwerkzugriffe schreiben zu müssen. Die zur Unterstützung von Protokollen (in GNOME-VFS: "Schemen") notwendigen Routinen sind in dynamisch geladenen Modulen untergebracht, so dass beliebige neue Protokollhandler hinzugefügt werden können.

GNOME-VFS erweitert das URI-Konzept um `verschachtelte Schemen'. Das heißt, dass in einer Adresse ein weiteres Schema angehängt werden kann, mit dem das Ergebnis des vorigen Schemas geöffnet wird. So bedeutet beispielsweise ein URI wie "http://www.revival-revival.de/dublin78.tar.gz#gzip#tar/dublin78/wasn-brett.mp3" GNOME-VFS, ein Archivdatei aus dem Netz herunterzuladen, zu dekomprimieren und aus ihr eine bestimmte Datei zu entnehmen.

Über all dies hinaus liefert GNOME-VFS auch eine Menge praktischer Hilfsfunktionen mit, allen voran ein Subsystem für asynchrone Zugriffe. Dies ist für moderne grafische Anwendungen von immenser Bedeutung -- nur indem Dateizugriffe asynchron, das heißt, im Hintergrund, verlaufen, kann sichergestellt werden, dass Anwendungen auch während langen Zugriffen bedienbar bleiben.

GNOME-VFS übernimmt zu guter Letzt auch noch die Zuordnung zwischen Dateien und MIME-Typen einerseits sowie MIME-Typen und darauf arbeitenden Anwendungen andererseits. Das komplette Verknüpfungssystem ist nicht nur über den entsprechenden Konfigurationsdialog für den Benutzer, sondern über eine API auch für den Entwickler zugänglich.

Einbindung in die Infrastruktur: Menüeinträge und Dateitypen

Dies führt direkt zum nächsten Punkt, dem Einbinden von Anwendungen in die GNOME-Infrastruktur. Programme sollten im GNOME-Hauptmenü aufrufbar sein und außerdem bekannt geben, welche Dateitypen sie öffnen können.

Ersteres geschieht über einen .desktop-Eintrag im Verzeichnis share/applications des GNOME-Installationsbaumes. Das Format von .desktop-Dateien ist standardisiert (KDE verwendet dasselbe); der Eintrag nimmt Name, Beschreibung, Aufrufname, Kategorisierung etc. der Anwendung auf und landet automatisch im GNOME-Menü. Ein Beispiel sehen Sie hier (der Übersichtlichkeit halber wurden nur die deutschen und französischen Übersetzungen der natürlichsprachigen Einträge übernommen):

[Desktop Entry]
Encoding=UTF-8
Name=PDF file viewer
Name[de]=PDF-Dateibetrachter
Name[fr]=Visualiseur de fichier PDF
Comment=Tool for viewing PDF files
Comment[de]=Werkzeug zur Anzeige von PDF-Dateien
Comment[fr]=Visualiseur de fichier PDF (Portable Document Format)
Exec=gpdf
Icon=document-icons/gnome-application-pdf.png
Terminal=false
Type=Application
Categories=GNOME;Application;Graphics;VectorGraphics;Viewer;
StartupNotify=true
		

Das Verknüpfen von Dokumenttypen mit einer Anwendung ist geringfügig schwerer. Strenggenommen kann ein Dateityp gar nicht mit einer Anwendung verknüpft werden, sondern es kann nur ein neuer MIME-Typ für einen oder mehrere bestimmte Dateitypen deklariert und andererseits die Unterstützung einer Anwendung für bestimmte MIME-Typen bekannt gegeben werden.

Die Deklaration neuer MIME-Typen geschieht zum Beispiel, indem eine Datei mit dem Suffix .mime in das Verzeichnis share/mime-info des GNOME-Baumes kopiert wird. Eine solche Datei kann beliebig viele MIME-Typen deklarieren und Erkennungsmerkmale wie Dateinamensuffixe o.Ä. angeben. Hat eine Anwendung allerdings keinen eigenen, neuartigen Dateityp, reichen die zahlreichen von GNOME-VFS vorgegebenen Erkennungsheuristiken zur Bestimmung zahlloser mehr oder weniger gängiger MIME-Typen durchweg aus. Hier trotzdem zur Veranschaulichung die Datei gnumeric.mime, die alle von der GNOME-Tabellenkalkulation Gnumeric neu deklarierten MIME-Typen an Dateinamensuffixe bindet:

application/x-gnumeric
	ext: gnumeric

application/vnd.ms-excel
	ext: xls xlw 

application/x-applix-spreadsheet
	ext: as 

application/vnd.lotus-1-2-3
	ext: 123 wk4 wk3 wk1
	  </programlisting>

	  <para>Unterstützung für ein oder mehrere MIME-Typen wird bekanntgegeben
		durch Dateien mit dem Suffix .keys im selben Verzeichnis. Sehen Sie
		hierzu einen ebenfalls weitgehend selbsterklärenden Abschnitt aus gnumeric.keys:</para>

	  <programlisting>
<![CDATA[application/x-gnumeric:
        open=gnumeric %f
        view=gnumeric %f
        icon-filename=/gnome/garnome/share/pixmaps/gnumeric/gnome-application-x-gnumeric.png
 
application/vnd.ms-excel:
        open=gnumeric %f
        view=gnumeric %f
        icon-filename=/gnome/garnome/share/pixmaps/gnumeric/gnome-application-x-xls.png
 
application/vnd.lotus-1-2-3:
        open=gnumeric %f
        view=gnumeric %f
        icon-filename=/gnome/garnome/share/pixmaps/gnumeric/gnome-application-vnd.lotus-1-2-3.png
	  

Ergonomische Gestaltung

Lange Zeit hatten sowohl die Kernkomponenten von GNOME als auch auf der GNOME-Plattform aufsetzende Drittanwendungen das Problem mangelnder Konsistenz in der Benutzerführung. Selbst in einfachen Dingen wie der Benennung und Anordnung von Menüeinträgen gab es jahrelang keine Konventionen.

Selbst kleine Inkonsistenzen führen jedoch bereits zur Verwirrung der Benutzer, zu Verzögerungen in der Bedienung und damit zum Verlust von Produktivität. Der Anspruch von Ästhetik, Einheitlichkeit und Benutzerfreundlichkeit, den GNOME sich selbst stellt, kann nur eingelöst werden, wenn es einheitliche Richtlinien für die Gestaltung von GNOME-Anwendungen gibt.

Mit den seit August 2002 vorliegenden GNOME Human Interface Guidelines gibt es solche Richtlinien nun. Es würde den Rahmen dieses Skripts sprengen, im Einzelnen abzuhandeln, worin all diese Richtlinien bestehen. Von allgemeinen Regeln zur Ergonomie bis hin in die Details des visuellen Design von Anwendungen hinein geben die HIG GNOME-Entwicklern eine umfassende Hilfe zur ergonomischen, standardkonformen Gestaltung von Anwendungen an die Hand.

Erwähnenswert ist vielleicht, dass den HIG das Ideal der visuell ruhigen Anwendung zu Grunde liegt -- das heißt: Abstände statt Linien zur optischen Gruppierung; keine Überladung von Fenstern mit Bedienelementen; klare, ausgerichtete Blöcke von Elementen statt Chaos. Betrachten Sie zum besseren Verständnis die folgenden Abbildungen, die ein Dialogfenster einmal vor und einmal nach der richtlinienkonformen Umgestaltung zeigen.

Vorher:

Nachher:

Barrierefreiheit

Unter diesem Schlagwort versteht man in der Programmierung dasselbe wie in der Architektur: nämlich, so zu planen, dass von vornherein keine Zugangshindernisse für Behinderte entstehen -- so müssen auch nachträglich keine überbrückt werden.

Barrierefreiheit in der GNOME-Programmierung bedeutet zuallererst korrekte und aussagekräftige Beschriftung sowie Erreichbarkeit aller Bedienelemente einer Anwendung von der Tastatur aus. GTK+ und GNOME stellen dafür komfortable Hilfsfunktionen bereit, so dass es keinen großen Zusatzaufwand bedeutet, hierfür zu sorgen. Da GTK+' mitgelieferte Widgets ihre Daten ohnehin über das Accessibility Toolkit ATK weitergeben, muss nur bei selbstentwickelten Widgets diese `von Hand' eingebaut werden.

Abgesehen von der für nichtbehinderte Benutzer bereits sehr angenehmen Tastaturbedienbarkeit stellt dies auch sicher, dass Zusatzanwendungen wie Bildschirmvorleser, Vergrößerungswerkzeuge, Bildschirmtastaturen usw. in die Anwendung eingreifen können. Ein weiterer Nebeneffekt ist somit, dass es später einmal sehr einfach sein wird, solchermaßen zugängliche Software von einem Makrorekorder o.Ä. fernzusteuern.

Außer im Code selber ist Barrierefreiheit auch noch in Teilen des visuellen Designs zu berücksichtigen; zum Beispiel sollten Symbole sich auch von Farbenblinden noch unterscheiden lassen können. Bei den im Repertoire von GTK+ bzw. GNOME enthaltenen Standardsymbolen ist dies weniger ein Problem, da spezielle Icon-Themen mit besonders großen und/oder kontrastreichen Symbolen existieren.