GNOME als Entwicklungsplattform

Linux - Wegweiser zur Installation & Konfiguration, 3. Auflage

Online-Version

Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen.

Wünschen Sie mehr Informationen zu der gedruckten Version des Buches Linux - Wegweiser zur Installation & Konfiguration oder wollen Sie es bestellen, dann klicken Sie bitte hier.

GNOME als Entwicklungsplattform

Während GNOME Unix-basierte Betriebssysteme sicherlich anwenderfreundlicher machen kann, verbringt das GNOME-Team ebensoviel Zeit damit, auch die Programmierung angenehmer zu machen.

Aus Sicht eines Entwicklers besteht GNOME aus einer Reihe von zentralen Bibliotheken, einer Infrastruktur für Komponentenprogrammierung und einer Anzahl von wiederverwendbaren, sprachneutralen Komponenten.

Die Basisbibliotheken von GNOME

Viele der mächtigen Features funktionieren dank dieser Bibliotheken in allen GNOME-Bibliotheken gleich.

GTK+ (GIMP-Toolkit)

GTK+ ist das objektorientierte graphische Toolkit von GNOME. Es wurde ursprünglich von den GIMP-Entwicklern entworfen, um ihre Arbeit am GIMP zu erleichtern. GNOME wählte GTK+ insbesondere deswegen, weil es ein Objektsystem mit reicher Funktionalität implementiert und bereits Bindungen für eine Reihe von Programmiersprachen bereitstellt. Damit trägt GTK+ bereits zu einem großen Teil zum Ziel von GNOME bei, unabhängig von einzelnen Programmiersprachen zu sein. Weitere Informationen dazu finden Sie unter http://www.gtk.org.

Es wurden Richtlinien entwickelt, wie neue Sprachbindungen (sogenannte Wrapper) für die GTK+/GNOME-Bibliotheken hinzugefügt werden können. Entwickler, die sich an diese Richtlinien gehalten haben, haben Unterstützung für eine Reihe von Sprachen programmiert, darunter C++, Objective-C, TOM, Perl, Python, GUILE, ADA und andere. Weitere Bindungen befinden sich noch in der Entwicklung, was leicht verständlich ist, wenn man sich anschaut, aus wie vielen Bibliotheken GNOME besteht.

Das Objektsystem von GTK+ hat ein sehr elegantes Design und erlaubt sowohl klassische Einfachvererbung als auch das dynamische Erzeugen von neuen Methoden und Klassen. Weiter verfügt es über einen Signalmechanismus, der Signal-Handler dynamisch mit Ereignissen in der Benutzerschnittstelle (wie beispielsweise einem Mausklick) verbindet.

GTK+ wurde aber auch gewählt, weil es zum Erreichen des zweiten Projektziels beiträgt, dem Erschaffen einer intuitiven Desktop-Metapher. Dies geschieht durch die Unterstützung zweier Drag-und-Drop-Protokolle, Xdnd (X Drag und Drop) und M DnD. Damit können Objekte zwischen für GNOME geschriebenen Programmen (wie dem Desktop) und Programmen, die mit anderen Tools geschrieben wurden (wie Netscape), hin- und hergezogen werden. Weil GTK+ dies alles bereits selbst erledigt, bekommen die Anwendungsentwickler diese Funktionalität ohne eigenes Zutun.

Imlib

Hierbei handelt es sich um eine Bibliothek zur Bildverarbeitung, die schnelles Laden, Speichern und Anzeigen von Bildern ermöglicht. Imlib stellt fortgeschrittene Funktionen zum Cachen von Bildern und zur Farbverwaltung bereit, die selbst auf einfachen Displays oder 8-Bit-Videokarten noch effizient funktionieren. Wegen der Einschränkungen in der Farbverwaltung im X Window System müssen Entwickler, die direkt die X-Bibliotheken verwenden, sowie Icon-Designer bedenken, wie viele Farben ein bestimmtes Image wohl benötigt. Imlib enthebt Programmierer und Designer dieser Sorgen, indem es automatische Farbreduzierung und Dithering bereitstellt.

XML/DOM-Bibliotheken

Das WWW-Konsortium (die Organisation, die Standards für das World Wide Web absegnet) hat vor kurzem zwei neue Standards eingeführt: XML und DOM. Bei XML (eXtensible Mark-up Language) handelt es sich um eine Sprache, die verwendet werden kann, um andere Markup-Sprachen wie HTML zu entwickeln und zu beschreiben. Dank der vorhandenen, sauber programmierten XML-Bibliothek können GNOME-Entwickler sehr einfach portables Laden und Speichern strukturierter Daten in ihre Applikationen einbauen. DOM (Document Object Model) ist ein Modell, das beschreibt, wie Applikationen Datenbereiche in einem XML-Dokument ändern können. Das Implementieren dieser Standards als GNOME-Bibliotheken macht es Programmierern leichter, Applikationen zu schreiben, die XML und/oder DOM verwenden.

Die Canvas/Libart-Engines

Der Canvas ist eine Engine zum Erzeugen strukturierter Grafiken, mit denen Programmierer auf einfache Art interaktive graphische Anzeigen erstellen können. Dazu gehört auch unbeschränktes Scrollen und vollständige Flimmerfreiheit. Der Programmierer erzeugt einfach ein Canvas-Element (mitgeliefert werden Elemente wie Text, Image, Polygone und Gtk-Widgets) und gibt die gewünschte Position an. Der Canvas kümmert sich dann um den Rest.

Der Canvas wurde als erweiterbare, aber generische Display-Engine entwickelt. Beispielsweise verwendet die Tabellenkalkulation Gnumeric den Canvas, um das Tabellenblatt (spreadsheet) anzuzeigen, stellt aber auch eigene Erweiterungen bereit. Applikationen wie der GNOME-Kalender und der Dateimanager Midnight Commander verwenden die grundlegende Funktionalität des Canvas in ihren Anzeigen.

Libart ist eine Engine zur Manipulation und Darstellung von Vektoren, die Anti-Aliasing und Alpha-Komposition beinhaltet. Der Canvas setzt auf Libart auf und verwendet diese Bibliothek zum Darstellen der Objekte in einem RGB-Puffer. Libart macht es dem Canvas leicht, Ausgaben mit Anti-Aliasing und Alpha-Komposition zu erzeugen. Die Libart-Engine stellt eine Obermenge des Imaging-Modells von PostScript zur Erzeugung von Ausgaben sehr hoher Qualität bereit.

Das Komponenten- und Dokumentenmodell Bonobo

Bonobo ist der Name des Teilprojekts von GNOME, das zum Ziel hat, ein Komponentenmodell und einen Standard für die Interaktion zwischen den Komponenten eines komplexen Dokuments zu erschaffen.

Das Bonobo-Framework verfolgt ein ähnliches Konzept wie »Object Linking and Embedding« (OLE). Bonobo erlaubt es Programmierern, wiederverwendbare Software-Komponentenobjekte (ähnlich wie Active X-Controls) zu erzeugen. Außerdem ist Bonobo ein Dokumentenmodell, das ein System definiert, indem diese Objekte nahtlos mit gemeinsam genutzten Container-Dokumenten interagieren können (ähnlich wie »Linking and Embedding«).

Um ein Beispiel zu verwenden, das sicherlich vielen vertraut ist: In Microsoft Office kann ein Excel-Dokument in ein Word-Dokument eingebettet werden. Das Word-Dokument ist in diesem Fall ein Container-Dokument. Es enthält sowohl die Word- als auch die Excel-Daten. Wenn Sie aber auf die Excel-Daten klicken, dann können Sie mit diesen Daten arbeiten, als würden Sie sich gerade in Excel befinden, auch wenn die Excel-Daten in ein Word-Dokument eingebettet sind. Die Applikationsfunktionen von Excel als ein Bestandteil der Komponentensoftware erzeugen die Illusion, daß der Benutzer nur mit einer Applikation interagiert.

Bonobo besteht aus einer Reihe von CORBA-Schnittstellen, die zum Entwurf und zur Interaktion von Komponenten notwendig sind. Die Bonobo-Schnittstellen sind sowohl sprach- als auch Toolkit-unabhängig, und Bonobo-Dokumente können in jeder Sprache geschrieben und gelesen werden. Die Referenzimplementierung von Bonobo basiert auf dem Objektsystem von Gtk und bildet CORBA-Schnittstellen auf Gtk-Objekte ab, die vom Applikationsprogrammierer einfach angepaßt werden können.

Viele Programmierer verbinden OLE mit großer Komplexität, aber beachten Sie, daß das daran liegt, daß Microsoft OLE so entwerfen mußte, daß es gut in Windows hineinpaßt. Bonobo hat zwar über weite Strecken die gleiche Funktionalität wie OLE, ist aber ein viel einfacheres System, wenn es um das Verstehen und das Entwickeln von Software damit geht.

Common Object Request Broker Architecture (CORBA)

Unix ist immer wieder dafür gelobt worden, daß es es dem Benutzer einfach macht, eine Reihe von kleinen Filterprogrammen (wie grep oder sed) zu nehmen und diese mit Pipes zu verbinden, um eine komplexere, dem jeweiligen Bedarf angepaßte Applikation zu erzeugen. Leider lassen sich Pipes und Filter nicht sehr gut auf komplexere Applikationen (insbesondere graphische Applikationen) übertragen. GNOME ist eine Umgebung, in der Softwareobjekte miteinander auf eine standardisierte Art und Weise kommunizieren können (auch in einem Netzwerk), ohne etwas voneinander wissen zu müssen. Dies wird durch den CORBA-Unterbau von GNOME ermöglicht.

CORBA ist ein Softwaresystem, das vollständig auf offenen Standards basiert und Methoden spezifiziert, durch die Softwareobjekte miteinander interagieren. Diese Objekte kommunizieren miteinander über einen »Object Request Broker« (ORB), der den Datenverkehr durch all die verschiedenen Softwareschichten leitet. Der CORBA-Standard spezifiziert die Funktionalität, die ein ORB Client-Programmen bereitstellen muß. Die Objekte müssen nichts übereinander wissen, es kann sich bei ihnen um Programme handeln, die in verschiedenen Sprachen geschrieben sind, verschiedene Funktionen ausführen und sogar auf verschiedenen Rechnern laufen. Solange sie über den ORB kommunizieren, können alle miteinander reden.

CORBA zieht sich durch das ganze GNOME-System und stellt den Anwendungsentwicklern eine Vielzahl von Diensten bereit. Dazu gehören:

Ein allgemeiner IPC-Mechanismus (Inter-Process Communication) Früher war es unter Unix üblich, ein eigenes Protokoll zu entwickeln, wenn zwei Applikationen miteinander kommunizieren sollten. Man muß nicht erst erwähnen, daß das nicht gerade zur Wiederverwendbarkeit oder Interoperabilität von Software beigetragen hat. Wenn heutzutage GNOME-Applikationen miteinander kommunizieren müssen, dann können sie einfach CORBA verwenden.
Eine Möglichkeit, die interne Engine einer Applikation zu exportieren Viele Applikationen in GNOME exportieren ihre interne Funktionalität in die Außenwelt. Damit können andere Programme - sowohl GNOME- als auch Nicht-GNOME-Programme - diese von einer Applikation exportierten Dienste verwenden, was diese Applikationen besonders für Skriptsprachen zugänglich macht. Fortgeschrittene Anwender können so Skripten schreiben, um häufig wiederkehrende Aufgaben zu automatisieren. In nicht allzu ferner Zukunft werden Anwender ein Python-Skript schreiben können, das ein Spreadsheet in Gnumeric manipuliert, eine benutzerdefinierte Rechtschreibprüfung durchführt oder ähnliche wiederholte Aufgaben erledigt. Das entspricht in etwa der Funktionalität, die Visual Basic in Microsoft Office bereitstellt. The Grafikapplikation Guppi, der Dateimanager und die Tabellenkalkulation Gnumeric können derzeit so mit Skripten gesteuert werden.
Ein Verfahren zum Erzeugen wiederverwendbarer und interoperabler Softwarekomponenten Wie bereits erwähnt, baut das Bonobo-Komponenten- und Dokumentenmodell auf den von CORBA bereitgestellten Diensten auf und stellt ein Framework bereit, das sowohl Programmierern als auch Anwendern hohe Flexibilität bringt.

CORBA ist keine Software an sich, sondern enthält eine Reihe von Spezifikationen zum Entwerfen von »Object Request Brokern« (ORBs). Viele ORBs sind geschrieben worden, die die CORBA-Spezifikation erfüllen, aber alle sind unterschiedlich implementiert, und nicht jeder ORB ist für jedes Softwareprojekt geeignet. Das GNOME-Team hat lange nach einer passenden CORBA-Implementierung gesucht. Es brauchte einen ORB, der C-Sprachbindungen unterstützte und sowohl klein als auch schnell war. Schließlich wurde die Entscheidung getroffen, einen CORBA-ORB von Grund auf neu zu schreiben. Dick Porter, Elliot Lee (während seiner Arbeit für die Red Hat Labs) und Andrew Veliath schrieben einen völlig neuen und leistungsstarken CORBA-ORB namens ORBit. ORBit stellt schließlich all die Maschinerie bereit, die notwendig ist, um überall in GNOME CORBA zu verwenden. Eine Beschreibung von ORBit finden Sie unter http://www.labs.redhat.com/orbit.

Programmierwerkzeuge

Im Zuge der Weiterentwicklung des GNOME-Systems entstehen neue Entwicklungswerkzeuge, die Entwicklern beim Design von GUI-Applikationen helfen sollen. Besonders interessant ist dabei Glade von Damon Chaplin. Glade erleichtert das Erzeugen komplexer Benutzeroberflächen etwa so, wie der Interface Builder von NeXT dies unter NeXTStep tat.

Mittels GNOME DB, einer modifizierten CORBA-Schnittstelle zu diversen Datenbanken, kann jetzt einheitlich auf Datenbanken zugegriffen werden. Außerdem enthält GNOME DB ein Frontend für Designer. Dieses Projekt wird von Michael Lausch, der die Backend- und CORBA-Elemente schreibt, und Rodrigo Moya, der den GUI-Builder schreibt, geleitet.

Die Druckarchitektur von GNOME

Die freie Softwaregemeinde und Unix im allgemeinen haben lange Zeit auf eine standardisierte Druckarchitektur und ein qualitativ hochwertiges Imaging-Modell verzichten müssen. GNOME stellt eine ausgefeilte Druck-Engine bereit, deren Ziel es ist, zu standardisieren, wie Applikationen Druckausgaben machen.

GNOME-print (http://www.levien.com/gnome/print-arch.html) ist die Implementierung der Druckarchitektur von GNOME. Es besteht aus einer austauschbaren Darstellungs-Engine und einer Reihe von Standard-Widgets und -Dialogen zum Auswählen und Konfigurieren von Druckern. Außerdem ist GNOME-print für das Verwalten von Vektor-Fonts zuständig und enthält Skripten, die automatisch die bereits im System installierten Fonts finden.

Das Imaging-Modell von GNOME-print basiert auf dem Imaging-Modell von PostScript. Zu den grundlegenden Operationen gehören das Konstruieren von Vektor- und Bezier-Pfaden, das Zeichnen von Linien, das Ausfüllen von Flächen, das Abschneiden von Grafiken, die Ausgabe von Text (mit Type1-Fonts, TrueType-Ausgabe ist geplant) und das Drucken von Bildern.

Zur Zeit erzeugt GNOME-print nur PostScript-Ausgaben. Das Design des Imaging-Modells hängt aber eng mit dem der Darstellungs-Engine des Canvas zusammen, und es wird deswegen erwartet, daß diese beiden Module bald austauschbar sein werden. Insbesondere wird es möglich sein, in einen Canvas zu drucken, was nützlich ist, wenn eine qualitativ hochwertige Druckvorschau bereitgestellt werden soll. Außerdem wird man den Inhalt eines Canvas drukken können. Dies sollte das Design von Applikationen, die den Canvas verwenden, vereinfachen, weil nur sehr wenig zusätzlicher Code benötigt wird, um Druckfunktionalität zu implementieren.

Die GNOME-print-Engine wird auch dazu verwendet werden, gedruckte Seiten direkt darzustellen, ohne den zusätzlichen Schritt über PostScript zu machen. Dies ist besonders interessant, da es schnelles und qualitativ hochwertiges Drucken komplexer Seiten auf Farbtintenstrahldruckern ermöglichen wird. Komplexe Seiten sind beispielsweise solche, die Transparenz, Gradienten und andere Elemente enthalten, die im traditionellen PostScript-Imaging-Modell als schwierig gelten.

Weitere Informationen zum Linux - Wegweiser zur Installation & Konfiguration

Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center