ﾜberblick ber die GNOME-Entwicklungsplattform -- Material zum Vortrag "Einfhrung in die GNOME-Programmierung"

Die G-Welt

GNOME-Programmierung spielt sich in einer Welt ab, die ich auf Grund des inflation舐en Vorkommens des Anfangsbuchstabens G in Programm-, Bibliotheks-, Klassen-, Typ- und Funktionsnamen als `G-Welt' bezeichnen mhte. 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 Bndel von Bibliotheken

GNOME stellt sich nicht als eine groﾟe, monolithische Bibliothek dar, die alle Klassen und Funktionen bereitstellt, die GNOME-Funktionalit舩 ausmachen, sondern als ein ganzes Bndel einer (leider?) erstaunlich groﾟen Zahl von Einzelbibliotheken, die jeweils einen bestimmten Zweck erfllen. Nur einige davon exponieren jedoch fr den Entwickler wichtige APIs; zu ihnen gehen:

Der Dokumentationszustand der meisten dieser Bibliotheken hat sich in letzter Zeit um einiges verbessert, l舖st aber immer noch viel zu wnschen brig. An dieser Stelle sei erw臧nt, dass es mit DevHelp mittlerweile einen Hilfebrowser speziell fr 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臠e 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臧rt beispielsweise die Anwendung, wenn ein Konfigurationswert ge舅dert wurde? Welches Dateiformat wird verwendet, und wo landet die Datei? Was passiert, wenn die Konfigurationsdatei ge舅dert wird, w臧rend die Anwendung l舫ft? Und heiﾟt es nicht das Rad neu erfinden, diesen Mechanismus fr jede Anwendung neu zu schreiben?

GConf lt die Probleme auf ziemlich elegante Art und Weise. Es gibt eine zentrale Konfigurationsdatenbank, die eine als Verzeichnisbaum gegliederte Hierarchie von typbehafteten Schlsseln enth舁t, die Werte aufnehmen knen. Sie tun nunmehr folgendes:

Dies fhrt 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 Schlssel mssen 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舂lich 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' fr `Virtual File System'.

Warum nun aber ein virtuelles Dateisystem benutzen und nicht einfach auf das native zugreifen? Neben dem allf舁ligen Rechtfertigungsgrund fr Abstraktionsschichten, der Portabilit舩, geht es auch darum, den Begriff des Dateisystems zu erweitern -- mit GNOME-VFS knen 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舫len: 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舅gig davon, wo die Dateien sich befinden und in welcher Art auf sie zugegriffen wird. Wenn Sie also Ihre Zugriffe ber GNOME-VFS abwickeln, knen Sie berall dort, wo Sie sonst Dateinamen akzeptieren wrden, URIen akzeptieren und ihre Benutzer damit zum Beispiel Dateien, die irgendwo im Netz liegen, genauso zug舅glich machen wie lokale, ohne Code fr Netzwerkzugriffe schreiben zu mssen. Die zur Untersttzung von Protokollen (in GNOME-VFS: "Schemen") notwendigen Routinen sind in dynamisch geladenen Modulen untergebracht, so dass beliebige neue Protokollhandler hinzugefgt werden knen.

GNOME-VFS erweitert das URI-Konzept um `verschachtelte Schemen'. Das heiﾟt, dass in einer Adresse ein weiteres Schema angeh舅gt werden kann, mit dem das Ergebnis des vorigen Schemas gefnet 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 fr asynchrone Zugriffe. Dies ist fr moderne grafische Anwendungen von immenser Bedeutung -- nur indem Dateizugriffe asynchron, das heiﾟt, im Hintergrund, verlaufen, kann sichergestellt werden, dass Anwendungen auch w臧rend 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 Verknpfungssystem ist nicht nur ber den entsprechenden Konfigurationsdialog fr den Benutzer, sondern ber eine API auch fr den Entwickler zug舅glich.

Einbindung in die Infrastruktur: Meneintr臠e und Dateitypen

Dies fhrt direkt zum n臘hsten Punkt, dem Einbinden von Anwendungen in die GNOME-Infrastruktur. Programme sollten im GNOME-Hauptmen aufrufbar sein und auﾟerdem bekannt geben, welche Dateitypen sie fnen knen.

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ischen ﾜbersetzungen der natrlichsprachigen Eintr臠e 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 Verknpfen von Dokumenttypen mit einer Anwendung ist geringfgig schwerer. Strenggenommen kann ein Dateityp gar nicht mit einer Anwendung verknpft werden, sondern es kann nur ein neuer MIME-Typ fr einen oder mehrere bestimmte Dateitypen deklariert und andererseits die Untersttzung einer Anwendung fr 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舅giger 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>Untersttzung fr ein oder mehrere MIME-Typen wird bekanntgegeben
		durch Dateien mit dem Suffix .keys im selben Verzeichnis. Sehen Sie
		hierzu einen ebenfalls weitgehend selbsterkl舐enden 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 Benutzerfhrung. Selbst in einfachen Dingen wie der Benennung und Anordnung von Meneintr臠en gab es jahrelang keine Konventionen.

Selbst kleine Inkonsistenzen fhren jedoch bereits zur Verwirrung der Benutzer, zu Verzerungen in der Bedienung und damit zum Verlust von Produktivit舩. Der Anspruch von ﾄsthetik, Einheitlichkeit und Benutzerfreundlichkeit, den GNOME sich selbst stellt, kann nur eingelt werden, wenn es einheitliche Richtlinien fr die Gestaltung von GNOME-Anwendungen gibt.

Mit den seit August 2002 vorliegenden GNOME Human Interface Guidelines gibt es solche Richtlinien nun. Es wrde 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臧nenswert ist vielleicht, dass den HIG das Ideal der visuell ruhigen Anwendung zu Grunde liegt -- das heiﾟt: Abst舅de statt Linien zur optischen Gruppierung; keine ﾜberladung von Fenstern mit Bedienelementen; klare, ausgerichtete Blke von Elementen statt Chaos. Betrachten Sie zum besseren Verst舅dnis 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舂lich, so zu planen, dass von vornherein keine Zugangshindernisse fr Behinderte entstehen -- so mssen auch nachtr臠lich keine berbrckt werden.

Barrierefreiheit in der GNOME-Programmierung bedeutet zuallererst korrekte und aussagekr臟tige Beschriftung sowie Erreichbarkeit aller Bedienelemente einer Anwendung von der Tastatur aus. GTK+ und GNOME stellen dafr komfortable Hilfsfunktionen bereit, so dass es keinen groﾟen Zusatzaufwand bedeutet, hierfr 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 fr nichtbehinderte Benutzer bereits sehr angenehmen Tastaturbedienbarkeit stellt dies auch sicher, dass Zusatzanwendungen wie Bildschirmvorleser, Vergrerungswerkzeuge, Bildschirmtastaturen usw. in die Anwendung eingreifen knen. Ein weiterer Nebeneffekt ist somit, dass es sp舩er einmal sehr einfach sein wird, solchermaﾟen zug舅gliche Software von einem Makrorekorder o.ﾄ. fernzusteuern.

Auﾟer im Code selber ist Barrierefreiheit auch noch in Teilen des visuellen Designs zu bercksichtigen; zum Beispiel sollten Symbole sich auch von Farbenblinden noch unterscheiden lassen knen. 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.