Kapitel 14 Xlib – X Window-Programmierung

In diesem Kapitel kommen Sie mit der tiefsten Ebene der Grafikprogrammierung in Berührung – der X Window-Programmierung mit der Xlib-Bibliothek.

Ursprünglich war zu diesem Thema ein sehr umfangreiches Kapitel eingeplant. Die X Window-Programmierung ist hierzulande ein selten beschriebenes Thema. Aber alleine schon die Dokumentation zur Xlib (Bibliothek für die X Window-Programmierung) hat ohne jeden Quellcode schon über 500 Seiten Umfang. Dabei hat man noch keinen einzigen Button auf dem Bildschirm gezeichnet. Daher ist anschließend noch weitere Dokumentation zu einem der Toolkits (z. B. Xt) nötig, wo die reine Dokumentation wieder ein paar hundert Seiten stark ist. Somit müssen Sie sich hier mit einer sehr bescheidenen Einführung in das Thema begnügen.

Auf der anderen Seite ist es auch nicht unbedingt nötig, sich mit der Xlib zu befassen, um Anwendungen mit einer grafischen Oberfläche zu entwickeln. Sofern Sie nicht masochistisch sind, begnügen Sie sich wohl eher mit einem der vielen Toolkits (wie Xt, Tk, GTK+, Qt, Motif, Athena etc.), die alle auf der Xlib aufbauen.

Das X-System (auch »X11-System« genannt) wurde am Massachusetts Institute of Technology (MIT) in Zusammenarbeit mit der Firma DEC entwickelt. 1988 wurde daraus das MIT X Consortium gegründet, das die Arbeit fortführte, bis diese vom nächsten Konsortium – The Open Group – übernommen wurde. Am Schluss wurde die Entwicklung an X.org weitergegeben.

14.1 Architektur von X 

Eine der Besonderheiten von X ist die Netzwerkfähigkeit. X wurde im Gegensatz zu anderen Benutzeroberflächen wie z. B. MS Windows, die nicht auf einen im Netzwerk befindlichen Rechner getrimmt sind, für den Einsatz im Netzwerk entwickelt.

Damit ist es möglich, Anwendungen auf mehreren Workstations (die auch unabhängig vom Hersteller und Betriebssystem sind) in einem oder verschiedenen Netzwerken auszuführen – die Ein-/Ausgabe wird dabei von einer einzigen Workstation behandelt.

Damit dies funktioniert, wurde X als eine Client-Server-Architektur implementiert. Der Server ist dabei für die Ausgabe auf dem Bildschirm und die Verwaltung und Verteilung der Eingaben verantwortlich. Dadurch ist der Server auch von der Hardware des Systems abhängig, da die Verarbeitung der Ein-/Ausgabe auf die Hardware des Systems angepasst sein muss. Der Server hat Kontakt zur Hardware wie dem Bildschirm – aber auch zur Tastatur und Maus. Er ist natürlich maschinenspezifisch geschrieben und teilt zum Beispiel einer Clientanwendung mit, wenn der Benutzer den Mauszeiger in das zur Anwendung gehörende Fenster bewegt hat. Das Programm XF86_SVGA, das mittlerweile von XFREE86 abgelöst wurde, ist z. B. ein solcher Server für die Grafikkarte.

Auf der Clientseite hingegen werden die Anwendungen wie Büroprogramme, Datenbanken oder Spiele ausgeführt, die eines oder mehrere Fenster verwenden können. Natürlich gibt es noch ganz spezielle Clients – nämlich den Window-Manager. Vielleicht sind Sie ein wenig überrascht, dass ein Window-Manager wie z. B. mwm (Window Motif Manager), olwm (Open Look Window Manager) oder gar der KDE- und GNOME-Desktop auch nichts anderes sind als einfache Clients des X11-Servers. Theoretisch können Sie X auch ganz ohne einen Window-Manager ausführen, womit allerdings keine Veränderungen mehr in der Position und Größe des Fensters möglich wären.

Wie auch im Netzwerk, gibt es zwischen dem X-Server und dem X-Client ein Protokoll, mit dem beide kommunizieren, das schlicht und einfach X-Protokoll genannt wird. Natürlich ist das Protokoll (wie auch beim Netzwerkprotokoll) geräteunabhängig. (Sie sollten die Finger davon lassen, direkt mit dem Server zu kommunizieren.) Die Bibliothek Xlib bietet hierfür unzählige Funktionen für alle Fälle an. Das X-Protokoll definiert dabei verschiedene Päckchen, die mit Informationen gefüllt sind und zwischen dem Serverprogramm und dem Anwendungsprogramm transferiert werden. Es wird dabei zwischen vier Arten von solchen Päckchen unterschieden:

Request (Anfrage) – Protokollaufträge werden von der Xlib erzeugt und zum Server geschickt. Solch eine Anfrage enthält verschiedene Informationen für den Server – wie zum Beispiel eine Anweisung, dass eine Linie gezogen oder die Schriftfarbe verändert werden soll. Bei einigen Requests muss auf eine Antwort vom Server gewartet werden. Solche bezeichnet man als Round-Trip-Request und sollten recht sparsam eingesetzt werden, da diese die Performance erheblich einbremsen. Requests, die keine Antwort erwarten, werden als One-Way-Requests bezeichnet.

Reply (Antwort) – Wird dem Server ein Round-Trip-Request gesendet, so muss dieser mit einem Reply antworten.

Events (Ereignisse) – Der X-Server kontrolliert Eingabegeräte wie die Maus, Tastatur usw. auf Aktionen, die der Anwender auf diesen Geräten ausführen kann. Sämtliche Aktionen (Tastendruck, Mausbewegung etc.) werden vom Server registriert und als Event an das Anwendungsprogramm des Clients geschickt. Beim Client werden die Events bei Bedarf in einer Warteschlange abgelegt und der Reihe nach abgearbeitet.

Error (Fehler) – Fehler werden ähnlich wie Events behandelt. Die Xlib unterscheidet dabei zwischen einfach behebbaren und fatalen Fehlern. Dafür stehen wieder eigene Funktionen zur Verfügung.

14.1.1 Pufferung 

Wenn eine Anwendung eine Anfrage an den X-Server stellt, dann wird diese via X-Protokoll übertragen. Auch hier folgt der Datenaustausch, wie in einem Netzwerkbetrieb üblich, gepuffert. Die Daten werden dabei in kleine Päckchen gepackt und über das Netzwerk verschickt. Da eine einzelne Anfrage ein solches Päckchen selten ganz füllt, werden diese in einem Puffer gespeichert und erst dann verschickt, wenn dieser voll ist. Durch diese Vorgehensweise wird die Geschwindigkeit der Anwendung enorm erhöht. Dennoch gibt es drei Möglichkeiten, wann ein Päckchen verschickt werden kann, obwohl der Puffer noch nicht voll ist:

Die Anwendung wartet auf ein Ereignis, und es ist kein passendes in der Warteschlange – dieser Fall tritt am häufigsten auf.

Ein Round-Trip-Request verlangt sofort eine Antwort vom Server. Bei Funktionen, die einen Round-Trip-Request fordern, befinden sich meistens die Teilwörter Query, Fetch oder Get in der Syntax.

Der Client (also Sie mit Ihrer Applikation) entleert den Puffer selbst manuell, wenn z. B. kein Benutzer-Event und auch keine Anfrage an den Server erwartet wird.

14.1.2 Ressourcen 

Ressourcen sind in X nichts anderes als »gewöhnliche« Datenstrukturen, die beim Start einer X-Anwendung geladen, aber nicht direkt manipuliert werden können. Wird z. B. ein neues Fenster geöffnet, besitzt dieses eine Menge Eigenschaften und Merkmale wie u. a. die Größe, Position oder Sichtbarkeit. All diese Attribute werden in einer C-typischen Struktur gespeichert. So ist z. B. der Name der Struktur für ein Fenster Window. Neben der Struktur Window gibt es u. a. noch Strukturen für Pixmap, Colormap, Cursor, Font und den Graphical Context.