Das X-Window System

This text is available in German only.

Das X-Window System ist als offener, portabler Standard innerhalb des Projektes Athena am Massachusetts Institute of Technology entwickelt worden. Federführend zeigten sich dafür Robert W. Scheifler und Jim Gettys verantwortlich. Darüberhinaus gab es mehrere Mitwirkende aus den Reihen namenhafter Unternehmen, die die Zeichen der Zeit richtig zu deuten verstanden und sowohl als Sponsor bei den verschiedenen Projekten auftraten, als auch eigene Entwicklungen beisteuerten. Stellvertretend seien an dieser Stelle die Firmen DEC und IBM genannt, die mit Produkten wie dem Xt-Toolkit, das zusammen mit dem MIT-Stab entwickelt wurde, bzw. dem Andrew-Toolkit aufwarteten. Mit der Release 2 der Version 11 des X-Window Systems wurde die maßgebliche Entwicklung und Koordination dem XConsortium übertragen. Dieses setzt sich aus einer Gruppe von Wissenschaftlern, Firmen und freien Mitarbeitern zusammen, die seitdem planerisch und in der Entwicklung tätig sind.

Soll...

Während der ersten, konzeptionellen Planungen hatten die Entwickler bereits klare Ziele vor Augen, was Umfang und Funktionalität des X-Window Systems anging. Erdacht als portabler Standard, sollte X die Entwicklung graphischer Applikationen erheblich vereinfachen. Generischer Code, ermöglicht durch den Einsatz von Bibliotheken, sollte die eigentliche Programmerstellung erleichtern. Plattformübergreifende Verfügbarkeit sollte Entwicklungs- und Portierungszeiten verkürzen. Außerdem wurde auf diese Weise sichergestellt, daß das jeweilige Produkt nicht von vorne herein zur Isolation in Form einer Insellösung auf dem jeweils installierten System prädestiniert war. Eine normierte Schnittstelle für die Softwareerstellung versprach darüberhinaus bessere Wettbewerbsvorteile für die einzelnen Anbieter. Aber auch nicht-kommerzielle Software sollte von einer breiten Systembasis profitieren. Das X-Window System stellte die konsequente Weiterentwicklung von bisherigen textbasierten Netzwerkumgebungen dar. Die Textdarstellung wurde zu einem leistungsfähigen, graphischen Äquivalent erweitert, das neben Buchstaben und Zahlen auch komplexe Graphiken und Muster darzustellen vermochte. Bildschirmausgaben waren nicht mehr an statische Code-Tabellen gebunden, sondern vermochten sich nun besser den aktuellen Notwendigkeiten anzupassen, die Gegenstand der jeweiligen Anwendung waren. Eine entsprechend sinngerechte Präsentation der Ausgaben vereinfachte das Verständnis der Programme für die Benutzer und erlaubte ein bequemeres und effizienteres Arbeiten, mit kürzeren Einarbeitungszeiten. Die Erweiterung der Bildschirmeingabe auf Mouse oder Trackball gegenüber der alleinigen Tastatur ermöglichten neue Methoden der Interaktion. Das Potential für die grundlegende Dialogfähigkeit hatte sich gegenüber der puristischen Textein- und Ausgabe um ein Vielfaches weiterentwickelt.

Für Applikationen, die unter X entwickelt waren, bestanden keine Dependenzen bezüglich der installierten Workstation-Hardware. Die alleinige Voraussetzung für die entsprechende Darstellung war ein X-Terminal. Letztere mußten lediglich in der Lage sein, die durch das X-Protokoll über das Netz eintreffende Information zu verarbeiten. Auf der anderen Seite sollte das gemeinsame Protokoll jede Workstation, unabhängig von ihrem Hersteller, in die Lage versetzen, Benutzereingaben in der selben Weise an die betreffende Applikation zurückzuliefern. Das X-Protokoll selbst war von vorne herein als Netzwerkprotokoll ausgelegt. Workstation und Applikation liesen sich damit auf einfache Netzeinheiten abbilden. Sofern eine Netzverbindung zwischen beiden bestand, spielte es keine Rolle, an welchen Orten sich die jeweiligen Maschinen tatsächlich befanden. Natürlich konnten beide auch in einem Rechner zusammengefaßt werden, doch auch dann kam für deren Kommunikation und Steuerung mit einander ein Netzprotokoll zum Tragen, das die Möglichkeit offenhielt, eine der beiden Instanzen jederzeit auf einen anderen Host auszulagern. Multiplexing beschrieb einen Weg, mit einer Applikation mehrere Workstations bedienen zu können. Andererseits konnten auch mehrere Programme auf verschiedenen Rechnern auf ein und dieselbe Workstation zugreifen, sofern diese dies zulies. Die netzverbundene Zweisamkeit ging einher mit einer verblüffenden Einfachheit des eigentlichen Protokolls, das es ermöglichte, sowohl über schmal-, als auch über breitbandige Netzverbindungen arbeiten zu können, ohne hohe Netzlasten zu erzeugen.

... und Haben

Die strikte Trennung zwischen Workstation auf der einen und Anwendung auf der anderen Seite manifestiert sich in einer kompletten Transparenz für den Benutzer. Für letzteren ist nicht ohne weiteres erkennbar, ob ein Programm, dessen Output auf dem Bildschirm erscheint, sich der Ressourcen des lokalen Rechners bedient oder Rechenzeit auf einem peripheren System im Netz verbraucht. Diese grundlegende Infrastruktur gestattet es konzeptionell, rechenintensive Algorithmen von einem parallelen Hochleistungsrechner bearbeiten zu lassen, um diese schließlich auf einer beliebigen Workstation zu visualisieren. Andererseits können komplexe Bildschirmdarstellungen und 3D-Zeichnungen an dem Arbeitsplatz bearbeitet werden, der sich dazu aufgrund seiner Ergonomie am besten eignet. Applikationen sind in der Lage, ihre graphischen Ausgaben auf mehrere Bildschirme zu verteilen. Das X-Window System kann einer einzelnen Workstation mehr als einen Ausgabesschirm zuzuordnen, ist jedoch stets auf eine Tastatur/Mouse-Kombination beschränkt. Die Bearbeitung einer Projektumgebung und die Betrachtung entsprechender Resultate können auf verschiedene Bildschirme aufgeteilt werden. Diese können wiederum zu einer Workstation, oder aber zu unterschiedlichen Rechnern im Netz gehören. Auf der anderen Seite läßt sich der Bildschirm einer einzelnen Workstation dazu benutzen, viele verschiedene Informationen unterschiedlicher Rechner auf einmal darzustellen. Die Implementierung eines zentralen Kontrollorgans wird auf diese Weise erheblich vereinfacht. Es ist denkbar, daß entsprechend essentielle Statusinformationen mehrerer, proprietärer Server auf einer Console erfaßt und protokolliert werden. Verschiedene Netzmanagement-Software-Pakete machen von diesen Möglichkeiten ausgiebig Gebrauch. Für Benutzer besitzen verteilte Systeme den Vorteil, an jedem, vom Netz aus zugänglichen, Arbeitsplatz ihre persönliche Arbeitsumgebung vorzufinden. Es spielt dabei keine Rolle, von welchem Gerät aus auf einen zentralen Datenbestand zugegriffen wird. Persönliche Einstellungen können selbst von solchen Workstations übernommen werden, die nur zur temporären Verfügung stehen. Die generische Informationsaufbereitung des X-Protokolls und die Anpassung an die tatsächliche Leistungsfähigkeit der Workstation macht den Unterschied zwischen Maschinen verschiedener Hersteller hinfällig.

Im Gegensatz zu Textterminals basiert die Informationsdarstellung von X-Workstations auf Bitmap-Graphik, womit sich als die kleinste darzustellende Bildschirmeinheit gegenüber einzelner Buchstaben oder Zeichen ein einzelner Punkt - ein Pixel - ergibt. Konglomerate aus Pixeln können sich zu Linien, Rechtecken, Buchstaben, Texten und anderen unregelmäßigen Formen zusammensetzen. Dadurch ist es praktisch möglich, jedes, beliebig denkbare, Bildschirmobjekt aus mehreren primitiven Formen zu erzeugen. Viele Workstations sind darüberhinaus in der Lage, einzelne Pixel mit unterschiedlichen Farben oder Graustufen darzustellen, was Benutzer graphische Zusammenhänge in anschaulicherer Weise begreifen läßt. Gegenüber schwarz-weißen Darstellungen besitzen farbige Gegenstücke im allgemeinen den Vorteil der übersichtlicheren Darstellung. Durch Farbe ist es Applikationen gezielt möglich, die Augen der Benutzer an bestimmte Bildschirmobjekte zu binden. Farbschattierungen und -Übergänge vermitteln ein naturgetreueres Abbild der realen Arbeitsumgebung. Entsprechende Signalfarben assoziieren Bildschirmobjekte mit unterschiedlichen Prioritätsstufen. Fehlermeldungen und Markierungen lassen sich gezielt von den übrigen Informationen hervorheben.

Die Darstellung von Bildschirmobjekten stellt die eine Richtung des Informationsflusses dar; Benutzereingaben die andere. Durch Ausgaben auf dem Schirm werden Benutzer zu entsprechenden Reaktionen veranlaßt. Wenn sich diese in Form von Eingaben manifestieren, kann die Anwendung erneut mit Rückfragen reagieren, oder den Programmfluß in eine andere Richtung fortsetzen. Durch diesen, denkbar einfachen, Kreislauf der Rückkoppelungen ist das System hinsichtlich der X-Window Philosophie abgeschlossen. Benutzer interagieren mit der jeweiligen Applikation durch Tastatur und Mouse. Gerade die Hinzunahme der Mouse gegenüber reinen Tastatursystemen hilft Eingaben von dem puren Augenblick der Betrachtung abzuheben. Mit der Mouse können Eingriffe unabhängig von dem aktuellen Text-Cursor vorgenommen werden, auf Anwenungen zugegriffen werden, die parallel zu der aktuellen am Bildschirm laufen und auf einfache Weise zwischen beiden hin- und hergeschaltet werden. Benutzer haben darüberhinaus vielfältige Möglichkeiten der Manipulation von Bildschirmobjekten und einer individuellen Gestaltung derselben. Dies gilt sowohl für die Interaktionen mit der jeweiligen Applikation, als auch grundlegender Variationen, wie das Verschieben und Stapeln von Fenstern auf dem Bildschirm, das Aktivieren von benutzerdefinierten Menüs und das Zusammenfalten von Fenstern zur späteren Verwendung. Zusammen mit der Tastatur werden die meisten denkbaren Interaktionsmöglichkeiten nachempfunden, die man von einer Nachbildung eines realen Schreibtisch-Arbeitsplatzes erwarten kann. Für spezielle Anwendungen ist die Erweiterung des Reservoirs um Eingabegeräte wie Trackball, 3D-Mouse oder Cyber-Glove denkbar, sofern dafür eine Softwareschnittstelle existiert.

Tiefgang

Die Darstellung von Daten und das Abfragen von Benutzerrückkoppelungen geschieht auf verschiedenen Komplexitätsebenen. Das X-Window System stellt Funktionen zur direkten Manipulation von einzelnen Pixeln, aber auch solche zum Erzeugen von bildschirmfüllenden Fenstern und deren Inhalten zur Verfügung. Das Schichtenmodell ermöglicht die Definition der Informationsstruktur von der Hardware bis zur eigentlichen Applikation.

X ist ein Netzwerkprotokoll

Auf einem passenden Trägermedium, das durch ein Koax-, TP- oder Glasfaserkabel gegeben sein kann, wird elementare Bit-Information übertragen. Definiert durch eine entsprechende Norm, wie Ethernet, etc., erfolgt ein passendes Framing auf Hardware-Ebene. Mit genügend redundanten Daten versehen und durch Fehlerkorrektur gegenüber äußeren Einflüssen hinreichend immunisiert, wird die Information in Byte-Paketen von Punkt A nach Punkt B transpotiert. Dazu wird ein entsprechendes Transportprotokoll, wie IP oder X.25, verwendet. Damit die Daten den Empfänger auch in der Weise erreichen, wie ursprünglich geplant, wird deren Transport darüberhinaus mit TCP, etc., kontrolliert. Die zu übertragende Nutzinformation ist es schließlich, die zwischen Applikation und Workstation ausgetauscht wird. Der eigentliche Informationsaustausch bleibt der jeweiligen Anwendung verborgen. Übertragung und Handshake erfolgen unter völliger Transparenz tieferer Netzwerkmechanismen.

X ist ein Graphikprotokoll

Anhand verschiedener Richtlinien werden Regeln definiert, nach denen Parameter für graphische Darstellungen gewählt werden können. Durch Bibliotheksaufrufe werden Funktionen mit den entsprechenden Parametern zu semantischen Objekten zusammengefaßt und ausgeführt. Wenn die Anwendung nicht auf dem lokalen Rechner läuft, werden die Funktionsaufrufe über das Netz an die Workstation weitergeleitet. Diese versucht, solange keine internen Probleme auftreten, den Befehl in eine graphische Low-Level-Funktion in deren BIOS oder ROM umzusetzen. Daraufhin werden entsprechende Pixel einzeln oder über gegebenenfalls vorhandene Blit-Operationen angesprochen.

X ist ein Input-Handling-Protokoll

Benutzereingaben von Mouse und Tastatur werden in Schlangen zusammengefaßt und der Applikation mitgeteilt. Es ist nun Sache des Programmes die eingehenden Eingaben der Reihe nach, oder in beliebiger Form, abzuarbeiten. Das Programm ist weiterhin in der Lage, aus der Menge aller möglichen Nachrichten nur eine bestimmte Teilmenge zu selektieren und sich lediglich Nachrichten zustellen zu lassen, die dieser Teilmenge zugehörig sind.

Die konsequent netzorientierte Ausrichtung des X-Protokolls hat stets zur Folge, daß eine (oder mehrere) Applikation(en) mit einer (oder mehrerer) Workstation(s) kommunizier[t,{en}]. Diese Polarisierung ist selbst dann zu beobachten, wenn mehrere Netzverbindungen parallel gehalten werden, d. h. ein Partner (peer) über mehrere Verbindungen mit mehreren anderen Informationen austauscht. In den meisten Fällen stellt sich die Situation so dar, daß eine Anwendung von der Workstation die Ausführung einer Operation erbittet. Von Zeit zu Zeit reagiert die Workstation mit Eingaben des Benutzers. Diese Symbiose wird als Client-Server-Verbindung betrachtet, wie man sie auch aus dem Sprachgebrauch von anderen Netzwerkumgebungen kennt. Im allgemeinen wird dann mit dem Server ein Rechner großer Plattenkapazität oder einem zentralen Dienstleistungsmerkmal bezeichnet. Mit Client wird folglich jener Rechner assoziiert, von dem aus der Benutzer eine bestimmte Dienstleistung in Anspruch zu nehmen gedenkt, also im allgemeinen der Rechner, an dem der Benutzer sitzt. Zum Leidwesen vieler Anwender wird die Bezeichnung der Peers im Zusammenhang mit dem X-Window System genau anders herum gewählt: Aus der Sicht der Applikation wird auf der Workstation um die Ausführung einer Dienstleistung gebeten. Die Workstation ist der Server, das Arbeitspferd, dessen Tun sich im wesentlichen an den Belangen des Client ausrichtet. Von Zeit zu Zeit sendet auch der Server eigenständig Nachrichten an den Client, etwa in Form von Benutzereingaben, aber auch hier legt einzig und alleine der Client fest, auf welche Art von Ereignissen diese Übertragungen beschränkt bleiben sollen.

Flink, flink

Ein Eckpfeiler der Definition des X-Protokolls stellt dessen Implementierung im Hinblick auf Effizienz und Performance dar. Es existieren verschiedene Mechanismen, um die Ausführung einzelner Befehle oder Befehlsgruppen zu beschleunigen. Eine essentielle Methode ist das Buffering. Sowohl auf der Seite der Applikation, als auch auf der der Workstation werden Befehlsfolgen gepuffert. Nachdem es sich bei dem X-Protokoll um ein Netzprotokoll handelt, wirkt sich die Technik in vielerlei Hinsicht positiv auf die zu erwartende Performance aus. Bei einer großen Anzahl von zu übertragenden Elementen wäre das Verschicken einzelner Befehle nicht ökonomisch. Vielmehr ist es sinnvoll, mehrere gleichartige Befehle zusammenzufassen, um die Paketgrößen der Netzschicht besser ausnutzen zu können, was vor allem bei größeren Entfernungen über mehrere Hubs zum Tragen kommt. Diese Vorgehensweise kommt auch dem Netz selbst zu Gute, indem unnötige Netzlast durch fragmentierten "X-Traffic" vermieden wird. Natürlich kann auch bereits auf höherer Ebene damit begonnen werden, das anfallende Datenvolumen zu reduzieren. Ein reguläres Rechteck oder eine Linie aus einzelnen Punktbefehlen aufzubauen, stellt keinen sinnvollen Weg dar, dem Problem zu begegnen. Hier ist die Verwendung eines entsprechenden Kommandos zum Zeichnen von Rechtecken oder Linien um ein vielfaches effizienter, wenngleich die geometrische Beschreibung identisch sein mag. Zum einen muß dadurch nur ein einzelner Befehl an die Workstation gesendet werden. Zum anderen ist letztere im allgemeinen in der Lage, ein Rechteck durch proprietäre Hardwarefunktionen wesentlich schneller zu zeichnen, als entsprechende Punktmengen in der Mächtigkeit des Produktes der Seitenlängen.

In der Client-Server-Beziehung werden die Personengruppen, die sich hinter dem jeweiligen Peer verbergen oft mit diesem in Verbindung gebracht. So verbirgt sich hinter dem Server, der Workstation, ein realer Benutzer, der an einem realen Schreibtisch sitzt und mit der Bedienung einer Anwendung beschäftigt ist, bzw. mit dem virtuellen Desktop interagiert. Für den Anwender sind alles andere, als der Bildschirm, die Mouse und die Tastatur abstrakte Objekte, die er weder sieht, noch direkt beeinflussen kann. Nur durch die Interaktion mit Mouse und Tastatur kann er mit der eigentlichen Applikation, dem Programm, kommunizieren. Dieses wiederum, als Client bezeichnet, kann versuchen die Benutzereingaben auszuwerten und die Workstation dazu veranlassen, bestimmte Bildschirmobjekte so umzustellen, daß es dem Benutzer erscheint, als interagiere er tatsächlich direkt mit ihnen. Eine flüssige Rückkoppelung von Client und Server ist also in hohem Maße davon abhängig, wie sauber die virtuelle Benutzerschnittstelle implementiert worden ist.

Die Philosophie des X-Window Systems sieht vor, Möglichkeiten der graphischen Interaktion zwischen Benutzer und Anwendung zu offerieren. Zu diesem Zweck werden einige elementare Techniken geliefert, die eine logische Infrastruktur definieren. Der Programmierer bedient sich aus einem Vorrat an Funktionen und stellt seinerseits dem Benutzer eine Applikation zur Verfügung, von der er annimmt, das sie dessen Anforderungen genügt. Der Ressourcenvorrat und die Funktionsmerkmale des X-Window Systems beschränken sich absichtlich auf Schnittstellen relativ primitiver Art, die vom Umfang auf das Nötigste beschränkt sind. Es werden zum Beispiel Funktionen zum Erzeugen und Verschieben von Fenstern angeboten, nicht aber solche, um Slider-Bars oder ähnliches zur erzeugen, weil sich letztere durch entsprechende primitive Befehle synthetisieren lassen. Das X-Window System überläßt es dem Anwender oder Programmierer, sich hier entsprechender Window-Manager und X-Toolkits zu bedienen, die ein gewünschtes Look & Feel vermitteln.

Window Manager

Intern betrachtet das X-Window System alle Applikationen als gleichwertig. Es wird nicht etwa zwischen Supervisor- und User-Applikation unterschieden, wie es dem Benutzer im Zusammenhang mit einem Window Manager auf den ersten Blick erscheinen mag. Window Manager repräsentieren Anwendungen, die die alltägliche Handhabung mit der graphischen Benutzeroberfläche im allgemeinen und deren Objekten im besonderen realisiert. Der Window Manager stellt "nur" eine Anwendung dar, d. h., eine unter vielen. Insbesondere bedeutet dies, daß ein X-Server oder -Client nicht zwingend an einen bestimmten Manager gebunden ist und damit Benutzern die Quahl der Wahl läßt. Dies mag auch die Vielfalt der verschiedenen, verfügbaren Modelle erklären, die häufig mehr oder weniger auf einander aufbauen. Historisch gesehen stellen Programme wie der wm oder twm die Urväter der Window Manager dar. Daraus haben sich der fvwm mit allen seinen Ausprägungen und das XView-System entwickelt.

Aufgabe eines Window Manager ist die Verwaltung der Fensterdarstellungen auf dem Bildschirm. Darunter fallen Aufgaben, wie das benutzerfreie Verschieben, Platzieren, Stapeln und das Verändern der Größe von Fenstern. Diese Tätigkeit, die unabhängig von anderen Applikationen verrichtet wird, trägt in der Art und Weise wie der Manager sie durchführt wesentlich zum Look & Feel des jeweiligen Bildschirmarbeitsplatzes bei. Es steht dem Manager z.B. frei, anstatt eines formlosen Rahmens ein 3D-schattiertes "Griffbrett" um die Fenster zu zeichnen, die er verwaltet und dieses, abhängig davon, ob sich der Mousezeiger in dem jeweiligen Fenster befindet, mit verschiedenen Farben einzufärben. Desweiteren vermag er PopUp-Menüs auftauchen zu lassen, wenn in unterschiedlichen Regionen des Fensters bestimmte Mouse- und/oder Tastaturtastenkombinationen gedrückt werden, um Benutzern die Möglichkeit zu geben, eine Option auszuwählen. Einige Manager gehen in ihrer Konfigurierbarkeit sogar so weit, daß sie die Auswahl von Anzahl, Farbe und Form einzelner Window-Buttons und deren assoziierter Funktionen zulassen.

Toolkits

Die Möglichkeiten zur suggestiven und anschaulichen Gestaltung von Applikationen werden durch das X-Window System nur in Form primitiver Funktionen unterstützt. Es existieren Funktionen zum Zeichnen von elementaren, geometrischen Objekten, wie Punkten, Linien und Rechtecken in verschiedenen Farben und Mustern, nicht aber solche zum Zeichnen und Handhaben von Widgets, Schaltflächen, Menüs oder Auswahlfenster. Dies läßt auf der einen Seite die nahezu völlig freie Gestaltung der jeweiligen Applikation zu und bindet sie nicht an herstellerspezifische Vorgaben. Auf der anderen Seite wird jedoch die programmübergreifende, einheitliche Entwicklung erschwert. Gerade für Benutzer, die sonst an anderen graphischen, von der Programmbedienung her konsistenten Plattformen, wie dem Macintosh, arbeiten, ist es oft schwer, sich an die vielen verschiedenen Bedienungsmodelle und die dahinter steckenden Philosphien der unterschiedlichen Programme zu gewöhnen. Diesem Problem begegnen viele Programmierer durch die Verwendung von Toolkits. Toolkits vereinfachen zum einen die eigentliche Programmentwicklung in so fern erheblich, als daß sie ein bestimmtes Potential an höheren Funktionen besitzen und diese vom Programmierer nicht implementiert werden müssen. Zum anderen erleichtern sie die Bedienung des Programmes durch die konsistente Anordnung und Funktionalität von Bildschirmelementen. Einige Toolkits waren auf diese Weise in der Lage, diverse DeFacto-Standards zu etablieren. Dazu gehört vor allem OSFs Motif, daß jedoch auch gleichzeitig eines der kommerziell angebotenen Produkte darstellt. Neben den, in den frühen Tagen der X-Entwicklung entstandenen Toolkits wie Xt von MIT/DEC und Andrew von IBM haben auch viele nichtkommerzielle Toolkits breite Anwendung gefunden. Im Gegensatz zum elementaren X-Window System sind Toolkits in der Lage, standardisierte GUIs zu bieten, die in Form von modularisierten Unterprogrammbibliotheken geliefert werden. Programmübergreifende, intuitive Bedienung wird dadurch in vielen Fällen vereinfacht.