X Window System-Kernprotokoll - X Window System core protocol

Das X Window System-Logo

Das X Window System-Kernprotokoll ist das Basisprotokoll des X Window System , eines vernetzten Fenstersystems für Bitmap- Anzeigen, mit dem grafische Benutzeroberflächen unter Unix , Unix-ähnlichen und anderen Betriebssystemen erstellt werden . Das X Window System basiert auf einem Client-Server-Modell : Ein einzelner Server steuert die Eingabe- / Ausgabehardware wie Bildschirm , Tastatur und Maus . alle Anwendungsprogramme fungieren als Clients , mit dem der Interaktion Benutzern und mit den anderen Clients über den Server. Diese Interaktion wird durch das X Window System-Kernprotokoll geregelt. Es gibt andere Protokolle, die sich auf das X Window System beziehen. Beide werden oben im X Window System-Kernprotokoll oder als separate Protokolle erstellt.

Im X Window System-Kernprotokoll werden nur vier Arten von Paketen asynchron über das Netzwerk gesendet: Anforderungen, Antworten, Ereignisse und Fehler. Ein Client sendet Anforderungen an den Server, um ihn aufzufordern, einen Vorgang auszuführen (z. B. ein neues Fenster zu erstellen) und die darin enthaltenen Daten zurückzusenden. Der Server sendet Antworten , um diese Daten bereitzustellen. Ereignisse werden vom Server gesendet, um Clients über Benutzeraktivitäten oder andere Ereignisse zu informieren, an denen sie interessiert sind. Fehler sind Pakete, die vom Server gesendet werden, um einen Client über Fehler zu informieren, die während der Verarbeitung seiner Anforderungen aufgetreten sind. Anfragen können Antworten, Ereignisse und Fehler erzeugen. Abgesehen davon schreibt das Protokoll keine bestimmte Reihenfolge vor, in der Pakete über das Netzwerk gesendet werden. Es gibt einige Erweiterungen des Kernprotokolls, von denen jede ihre eigenen Anforderungen, Antworten, Ereignisse und Fehler hat.

X entstand 1984 am MIT (seine aktuelle Version X11 erschien im September 1987). Die Designer Bob Scheifler und Jim Gettys stellten als frühes Prinzip fest, dass das Kernprotokoll darin bestand, "Mechanismen zu schaffen, nicht Richtlinien". Infolgedessen spezifiziert das Kernprotokoll nicht die Interaktion zwischen Clients und zwischen einem Client und dem Benutzer. Diese Interaktionen sind Gegenstand separater Spezifikationen, wie z. B. der ICCCM- und der freedesktop.org- Spezifikation, und werden normalerweise automatisch mithilfe eines bestimmten Widget-Sets erzwungen .

Überblick

In diesem Beispiel nimmt der X-Server Eingaben von Tastatur und Maus entgegen und zeigt sie auf einem Bildschirm an. Ein Webbrowser und ein Terminalemulator werden auf der Workstation des Benutzers ausgeführt, und ein Terminalemulator wird auf einem Remote-Server ausgeführt, jedoch unter der Kontrolle des Computers des Benutzers. Beachten Sie, dass die Remoteanwendung genauso ausgeführt wird wie lokal.

Die Kommunikation zwischen Server und Clients erfolgt durch den Austausch von Paketen über einen Kanal . Die Verbindung wird vom Client hergestellt (wie der Client gestartet wird, ist im Protokoll nicht angegeben). Der Client sendet auch das erste Paket, das die zu verwendende Bytereihenfolge sowie Informationen über die Version des Protokolls und die Art der Authentifizierung enthält, die der Client vom Server erwartet. Der Server antwortet, indem er ein Paket zurücksendet, in dem die Annahme oder Ablehnung der Verbindung angegeben ist, oder eine weitere Authentifizierung anfordert . Wenn die Verbindung akzeptiert wird, enthält das Akzeptanzpaket Daten, die der Client für die nachfolgende Interaktion mit dem Server verwenden kann.

Eine beispielhafte Interaktion zwischen einem Client und einem Server.

Nachdem die Verbindung hergestellt wurde, werden vier Arten von Paketen zwischen Client und Server über den Kanal ausgetauscht:

  1. Anforderung: Der Client fordert Informationen vom Server an oder fordert ihn auf, eine Aktion auszuführen.
  2. Antwort: Der Server antwortet auf eine Anfrage. Nicht alle Anfragen generieren Antworten.
  3. Ereignis: Der Server informiert den Client über ein Ereignis, z. B. Tastatur- oder Mauseingabe, Verschieben, Ändern der Größe oder Belichtung eines Fensters usw.
  4. Fehler: Der Server sendet ein Fehlerpaket, wenn eine Anforderung ungültig ist. Da Anforderungen in die Warteschlange gestellt werden, werden von einer Anforderung generierte Fehlerpakete möglicherweise nicht sofort gesendet.

Anforderungs- und Antwortpakete haben eine unterschiedliche Länge, während Ereignis- und Fehlerpakete eine feste Länge von 32 Bytes haben .

Anforderungspakete werden vom Server fortlaufend nummeriert, sobald er sie empfängt: Die erste Anforderung von einem Client ist mit 1, die zweite mit 2 nummeriert usw. Die niedrigstwertigen 16 Bits der fortlaufenden Nummer einer Anforderung sind in der Antwort und dem Fehler enthalten Von der Anforderung generierte Pakete, falls vorhanden. Sie sind auch in Ereignispaketen enthalten, um die fortlaufende Nummer der Anforderung anzugeben, die der Server gerade verarbeitet oder gerade verarbeitet hat.

Windows

Was ist in der Regel ein Fenster in den meisten genannten grafischen Benutzeroberflächen ist ein sogenannte Top-Level - Fenster in dem X Window System. Der Begriff Fenster wird auch verwendet, um Fenster zu bezeichnen, die in einem anderen Fenster liegen, dh die Unterfenster eines übergeordneten Fensters . Grafische Elemente wie Schaltflächen , Menüs , Symbole usw. können über Unterfenster realisiert werden.

Eine mögliche Platzierung einiger Fenster: 1 ist das Stammfenster, das den gesamten Bildschirm abdeckt; 2 und 3 sind Fenster der obersten Ebene; 4 und 5 sind Unterfenster von 2. Die Teile eines Fensters, die sich außerhalb des übergeordneten Fensters befinden, sind nicht sichtbar.

Ein Client kann die Erstellung eines Fensters anfordern. Genauer gesagt kann die Erstellung eines Unterfensters eines vorhandenen Fensters angefordert werden. Infolgedessen werden die von Clients erstellten Fenster in einem Baum (einer Hierarchie) angeordnet. Das Stammverzeichnis dieses Baums ist das Stammfenster , ein spezielles Fenster, das vom Server beim Start automatisch erstellt wird. Alle anderen Fenster sind direkt oder indirekt Unterfenster des Stammfensters. Die Fenster der obersten Ebene sind die direkten Unterfenster des Stammfensters. Das Stammfenster ist sichtbar so groß wie der virtuelle Desktop und liegt hinter allen anderen Fenstern.

Es ist nicht immer garantiert, dass der Inhalt eines Fensters im Laufe der Zeit erhalten bleibt. Insbesondere kann der Fensterinhalt zerstört werden, wenn das Fenster verschoben, in der Größe geändert, von anderen Fenstern abgedeckt und im Allgemeinen ganz oder teilweise nicht sichtbar gemacht wird. Insbesondere geht Inhalt verloren, wenn der X-Server keinen Sicherungsspeicher für den Fensterinhalt verwaltet. Der Client kann einen Sicherungsspeicher für die Wartung eines Fensters anfordern, der Server ist jedoch nicht dazu verpflichtet. Daher können Clients nicht davon ausgehen, dass der Sicherungsspeicher beibehalten wird. Wenn ein sichtbarer Teil eines Fensters einen nicht angegebenen Inhalt hat, wird ein Ereignis gesendet, um den Client zu benachrichtigen, dass der Fensterinhalt erneut gezeichnet werden muss.

Jedem Fenster sind Attribute zugeordnet , z. B. die Geometrie des Fensters (Größe und Position), das Hintergrundbild, ob ein Sicherungsspeicher angefordert wurde usw. Das Protokoll enthält Anforderungen an einen Client, die Attribute zu überprüfen und zu ändern eines Fensters.

Windows kann InputOutput oder sein InputOnly . InputOutput Fenster können auf dem Bildschirm angezeigt werden und werden zum Zeichnen verwendet. InputOnly Fenster werden nie auf dem Bildschirm angezeigt und nur zum Empfangen von Eingaben verwendet.

Anatomie eines FVWM- Fensters. Der weiße Bereich ist das Fenster, das von der Clientanwendung erstellt und angezeigt wird.

Der dekorative Rahmen und die Titelleiste (möglicherweise einschließlich Schaltflächen), die normalerweise um Fenster herum angezeigt werden, werden vom Fenstermanager erstellt , nicht vom Client, der das Fenster erstellt. Der Fenstermanager verarbeitet auch Eingaben in Bezug auf diese Elemente, z. B. die Größenänderung des Fensters, wenn der Benutzer auf den Fensterrahmen klickt und ihn zieht. Clients arbeiten normalerweise mit dem von ihnen erstellten Fenster, ohne die vom Fenstermanager vorgenommenen Änderungen zu berücksichtigen. Eine Änderung, die berücksichtigt werden muss, besteht darin, dass die erneute Elternschaft von Fenstermanagern , wie es fast alle modernen Fenstermanager sind, die übergeordneten Fenster von Fenstern der obersten Ebene in ein Fenster ändert, das nicht das Stammverzeichnis ist. Aus Sicht des Kernprotokolls ist der Fenstermanager ein Client, der sich nicht von den anderen Anwendungen unterscheidet.

Daten zu einem Fenster können durch Ausführen des xwininfo Programms abgerufen werden . Dieses Programm übergibt das -tree Befehlszeilenargument und zeigt den Baum der Unterfenster eines Fensters zusammen mit ihren Bezeichnern und Geometriedaten.

Pixmaps und Drawables

Eine Pixmap ist ein Speicherbereich, der zum Zeichnen verwendet werden kann. Im Gegensatz zu Windows werden Pixmaps nicht automatisch auf dem Bildschirm angezeigt. Der Inhalt einer Pixmap (oder eines Teils davon) kann jedoch in ein Fenster übertragen werden und umgekehrt. Dies ermöglicht Techniken wie Doppelpufferung . Die meisten grafischen Operationen, die unter Windows ausgeführt werden können, können auch auf Pixmaps ausgeführt werden.

Windows und Pixmaps werden gemeinsam als Drawables bezeichnet , und ihre Inhaltsdaten befinden sich auf dem Server. Ein Client kann jedoch anfordern, dass der Inhalt eines Zeichens vom Server auf den Client übertragen wird oder umgekehrt.

Grafische Kontexte und Schriftarten

Der Client kann eine Reihe von Grafikvorgängen anfordern, z. B. das Löschen eines Bereichs, das Kopieren eines Bereichs in einen anderen, das Zeichnen von Punkten, Linien, Rechtecken und Text. Neben dem Löschen sind alle Vorgänge für alle Zeichenelemente möglich, sowohl für Fenster als auch für Pixmaps.

Die meisten Anforderungen für Grafikoperationen enthalten einen Grafikkontext , bei dem es sich um eine Struktur handelt, die die Parameter der Grafikoperationen enthält. Ein grafischer Kontext umfasst die Vordergrundfarbe, die Hintergrundfarbe, die Textschrift und andere grafische Parameter. Wenn der Client eine Grafikoperation anfordert, enthält er einen Grafikkontext. Nicht alle Parameter des Grafikkontexts wirken sich auf den Vorgang aus. Beispielsweise wirkt sich die Schriftart nicht auf das Zeichnen einer Linie aus.

Das Kernprotokoll gibt die Verwendung von serverseitigen Schriftarten an. Solche Schriftarten werden als Dateien gespeichert , und der Server greift entweder direkt über das lokale Dateisystem oder über das Netzwerk von einem anderen Programm namens Schriftartenserver auf sie zu . Clients können die Liste der für den Server verfügbaren Schriftarten anfordern und anfordern, dass eine Schriftart vom Server geladen (falls nicht bereits vorhanden) oder entladen (falls nicht von anderen Clients verwendet) wird. Ein Client kann allgemeine Informationen zu einer Schriftart anfordern (z. B. den Schriftaufstieg) und den Platz, den eine bestimmte Zeichenfolge beim Zeichnen mit einer bestimmten Schriftart einnimmt.

Das xfontsel Programm ermöglicht es dem Benutzer, die Glyphen einer Schriftart anzuzeigen.

Die Namen der Schriftarten sind beliebige Zeichenfolgen auf der Ebene des X Window-Kernprotokolls. Die Konventionen für die Beschreibung logischer X-Schriftarten legen fest, wie Schriftarten gemäß ihren Attributen benannt werden sollen. Diese Konventionen geben auch die Werte optionaler Eigenschaften an, die an Schriftarten angehängt werden können.

Das xlsfonts Programm druckt die Liste der auf dem Server gespeicherten Schriftarten. Das xfontsel Programm zeigt die Glyphen von Schriftarten an und ermöglicht es dem Benutzer, den Namen einer Schriftart auszuwählen, um sie in ein anderes Fenster einzufügen.

Die Verwendung von serverseitigen Schriftarten wird derzeit zugunsten von clientseitigen Schriftarten als veraltet angesehen. Solche Schriften werden vom Kunden, vom Server nicht mit der Unterstützung des gerenderten Xft oder kairos Bibliotheken und der XRender Erweiterung. Das Kernprotokoll enthält keine Angaben zu clientseitigen Schriftarten.

Ressourcen und Kennungen

Alle Daten zu Fenstern, Pixmaps, Schriftarten usw. werden auf dem Server gespeichert. Der Client kennt die Bezeichner dieser Objekte - Ganzzahlen, die er bei der Interaktion mit dem Server als Namen für sie verwendet. Wenn ein Client beispielsweise die Erstellung eines Fensters wünscht, fordert er den Server auf, ein Fenster mit einer bestimmten Kennung zu erstellen. Der Bezeichner kann später vom Client verwendet werden, um beispielsweise eine Zeichenfolge anzufordern, die im Fenster gezeichnet werden soll. Die folgenden Objekte befinden sich auf dem Server und sind dem Client über eine numerische Kennung bekannt:

  • Window
  • Pixmap
  • Font
  • Colormap (eine Farbtabelle, unten beschrieben)
  • Graphic context

Diese Objekte werden als Ressourcen bezeichnet . Wenn ein Client die Erstellung einer solchen Ressource anfordert, gibt er auch eine Kennung dafür an. Zum Erstellen eines neuen Fensters gibt der Client beispielsweise sowohl die Attribute des Fensters (übergeordnetes Element, Breite, Höhe usw.) als auch die dem Fenster zuzuordnende Kennung an.

Bezeichner sind 32-Bit- Ganzzahlen, deren drei höchstwertige Bits gleich Null sind. Jeder Client verfügt über eigene Kennungen, mit denen er neue Ressourcen erstellen kann. Dieser Satz wird vom Server als zwei Ganzzahlen angegeben, die im Akzeptanzpaket enthalten sind (das Paket, das er an den Client sendet, um ihn darüber zu informieren, dass die Verbindung akzeptiert wird). Clients wählen Bezeichner in diesem Satz so aus, dass sie nicht in Konflikt geraten: Zwei Objekte zwischen Fenstern, Pixmaps, Schriftarten, Farbkarten und grafischen Kontexten können nicht denselben Bezeichner haben.

Sobald eine Ressource erstellt wurde, wird ihre Kennung vom Client verwendet, um Operationen darüber an den Server anzufordern. Einige Vorgänge wirken sich auf die angegebene Ressource aus (z. B. Anforderungen zum Verschieben von Fenstern). andere fragen nach vom Server gespeicherten Ressourcendaten (z. B. nach den Attributen von Windows).

Bezeichner sind für den Server eindeutig, nicht nur für den Client. Beispielsweise haben keine zwei Fenster dieselbe Kennung, selbst wenn sie von zwei verschiedenen Clients erstellt wurden. Ein Client kann mit seiner Kennung auf jedes Objekt zugreifen. Insbesondere kann es auch auf Ressourcen zugreifen, die von einem anderen Client erstellt wurden, selbst wenn deren Kennungen außerhalb der von ihm erstellten Kennungen liegen.

Infolgedessen können zwei mit demselben Server verbundene Clients denselben Bezeichner verwenden, um auf dieselbe Ressource zu verweisen. Wenn ein Client beispielsweise ein Identifizierungsfenster erstellt 0x1e00021 und diese Nummer 0x1e00021 an eine andere Anwendung weitergibt (über alle verfügbaren Mittel, z. B. durch Speichern dieser Nummer in einer Datei, auf die auch die andere Anwendung zugreifen kann), kann diese andere Anwendung ausgeführt werden im selben Fenster. Diese Möglichkeit wird beispielsweise von der X Window-Version von Ghostview ausgenutzt : Dieses Programm erstellt ein Unterfenster, speichert seinen Bezeichner in einer Umgebungsvariablen und ruft Ghostscript auf . Dieses Programm zeichnet den Inhalt der PostScript- Datei, die in diesem Fenster angezeigt werden soll.

Ressourcen werden normalerweise zerstört, wenn der Client, der sie erstellt hat, die Verbindung zum Server schließt. Vor dem Schließen der Verbindung kann ein Client den Server jedoch auffordern, diese nicht zu zerstören.

Veranstaltungen

Ereignisse sind Pakete, die vom Server an einen Client gesendet werden, um mitzuteilen, dass etwas passiert ist, an dem der Client interessiert sein könnte. Ein Ereignis wird beispielsweise gesendet, wenn der Benutzer eine Taste drückt oder eine Maustaste klickt. Ereignisse werden nicht nur zur Eingabe verwendet: Beispielsweise werden Ereignisse gesendet, um die Erstellung neuer Unterfenster eines bestimmten Fensters anzuzeigen.

Jedes Ereignis ist relativ zu einem Fenster. Wenn der Benutzer beispielsweise klickt, wenn sich der Zeiger in einem Fenster befindet, ist das Ereignis relativ zu diesem Fenster. Das Ereignispaket enthält die Kennung dieses Fensters.

Ein Client kann den Server auffordern, ein Ereignis an einen anderen Client zu senden. Dies wird für die Kommunikation zwischen Clients verwendet. Ein solches Ereignis wird beispielsweise generiert, wenn ein Client den aktuell ausgewählten Text anfordert: Dieses Ereignis wird an den Client gesendet, der derzeit das Fenster mit der Auswahl verarbeitet.

Das Expose Ereignis wird gesendet, wenn ein Bereich eines Fensters zerstört und Inhalte sichtbar gemacht werden. Der Inhalt eines Fensters kann unter bestimmten Bedingungen zerstört werden, z. B. wenn das Fenster abgedeckt ist und der Server keinen Sicherungsspeicher verwaltet. Der Server generiert ein Expose Ereignis, um den Client zu benachrichtigen, dass ein Teil des Fensters gezeichnet werden muss.

Ein Beispiel für ein Ereignis: Wenn eine Taste in einem Fenster gedrückt wird, wird ein Ereignis generiert und abhängig von seiner Fensterereignismaske an einen Client gesendet, die der Client ändern kann.

Die meisten Arten von Ereignissen werden nur gesendet, wenn der Kunde zuvor ein Interesse an ihnen bekundet hat. Dies liegt daran, dass Kunden möglicherweise nur an bestimmten Veranstaltungen interessiert sind. Beispielsweise kann ein Client an Tastaturereignissen interessiert sein, nicht jedoch an Mausereignissen. Einige Arten von Ereignissen werden jedoch an Kunden gesendet, auch wenn sie diese nicht ausdrücklich angefordert haben.

Clients geben an, welche Arten von Ereignissen gesendet werden sollen, indem sie ein Attribut eines Fensters festlegen. Um beispielsweise ein Fenster neu zu zeichnen, wenn sein Inhalt zerstört wurde, muss ein Client die Expose Ereignisse empfangen , die ihn darüber informieren, dass das Fenster erneut gezeichnet werden muss. Der Kunde wird jedoch gesendet wird Expose Ereignisse nur dann , wenn der Kunde zuvor ihr Interesse an diesen Ereignissen festgestellt hat, die durch eine entsprechende Einstellung des erfolgte Ereignis Maske Attributs des Fensters.

Verschiedene Clients können Ereignisse im selben Fenster anfordern. Sie können sogar verschiedene Ereignismasken im selben Fenster festlegen. Beispielsweise kann ein Client nur Tastaturereignisse in einem Fenster anfordern, während ein anderer Client nur Mausereignisse in demselben Fenster anfordert. Dies ist möglich, weil der Server für jedes Fenster eine separate Ereignismaske für jeden Client verwaltet. Es gibt jedoch einige Arten von Ereignissen, die jeweils nur von einem Client für jedes Fenster ausgewählt werden können. Diese Ereignisse melden insbesondere Mausklicks und einige Änderungen im Zusammenhang mit der Fensterverwaltung.

Das xev Programm zeigt die Ereignisse relativ zu einem Fenster. Fordert insbesondere xev -id WID alle möglichen Ereignisse in Bezug auf das Fenster der Kennung an WID und druckt sie aus.

Beispiel

Das Folgende ist ein mögliches Beispiel für die Interaktion zwischen einem Server und einem Programm, das ein Fenster mit einer Blackbox erstellt und durch Drücken einer Taste beendet wird. In diesem Beispiel sendet der Server keine Antwort, da die Clientanforderungen keine Antworten generieren. Diese Anforderungen können zu Fehlern führen.

  1. Der Client öffnet die Verbindung zum Server und sendet das erste Paket unter Angabe der verwendeten Bytereihenfolge.
  2. Der Server akzeptiert die Verbindung (in diesem Beispiel ist keine Autorisierung erforderlich), indem er ein geeignetes Paket sendet, das andere Informationen enthält, z. B. die Kennung des Stammfensters (z. B. 0x0000002b ) und die vom Client erstellten Kennungen.
  3. Der Client fordert die Erstellung eines grafischen Standardkontexts mit Kennung an 0x00200000 (diese Anforderung generiert wie die anderen Anforderungen dieses Beispiels keine Antworten vom Server).
  4. Der Client fordert den Server auf, ein Fenster der obersten Ebene (dh das übergeordnete Fenster ist das Stammfenster 0x0000002b ) mit der Kennung 0x00200001 , der Größe 200 x 200, der Position (10, 10) usw. zu erstellen .
  5. Der Client fordert eine Änderung der Attribute des Fensters an und gibt an 0x00200001 , dass er an Empfängen Expose und KeyPress Ereignissen interessiert ist .
  6. Der Client fordert die Zuordnung des Fensters 0x00200001 an (auf dem Bildschirm angezeigt).
  7. Wenn das Fenster sichtbar gemacht wird und sein Inhalt gezeichnet werden muss, sendet der Server dem Client ein Expose Ereignis
  8. In Reaktion auf dieses Ereignis fordert der Client das Zeichnen eines Felds an, indem er eine PolyFillRectangle Anforderung mit Fenster- 0x00200001 und Grafikkontext sendet 0x00200000

Wenn das Fenster von einem anderen Fenster abgedeckt und wieder freigelegt wird, wird davon ausgegangen, dass der Hintergrundspeicher nicht beibehalten wird:

  1. Der Server sendet ein weiteres Expose Ereignis, um dem Client mitzuteilen, dass das Fenster erneut gezeichnet werden muss
  2. Der Client zeichnet das Fenster neu, indem er eine PolyFillRectangle Anfrage sendet

Wenn eine Taste gedrückt wird:

  1. Der Server sendet ein KeyPress Ereignis an den Client, um ihn darüber zu informieren, dass der Benutzer eine Taste gedrückt hat
  2. Der Client reagiert angemessen (in diesem Fall wird er beendet).

Farben

Auf Protokollebene wird eine Farbe durch eine vorzeichenlose 32-Bit-Ganzzahl dargestellt, die als Pixelwert bezeichnet wird . Die folgenden Elemente beeinflussen die Darstellung von Farben:

  1. die Farbtiefe
  2. Die Farbkarte , eine Tabelle mit Intensitätswerten für Rot, Grün und Blau
  3. Der visuelle Typ , der angibt, wie die Tabelle zur Darstellung von Farben verwendet wird

Im einfachsten Fall ist die Farbkarte eine Tabelle, die in jeder Zeile ein RGB- Tripel enthält . Ein Pixelwert x repräsentiert die Farbe in der x -ten Zeile der Tabelle. Wenn der Client die Einträge in der Farbkarte ändern kann, wird diese Darstellung durch die PseudoColor visuelle Klasse identifiziert . Die visuelle Klasse StaticColor ist ähnlich, aber der Client kann die Einträge in der Farbkarte nicht ändern.

Es gibt insgesamt sechs mögliche visuelle Klassen, von denen jede eine andere Art der Darstellung eines RGB-Tripels mit einem Pixelwert identifiziert. PseudoColor und StaticColor sind zwei. Weitere zwei sind GrayScale und StaticGray , die sich darin unterscheiden, dass sie nur Graustufen anzeigen.

Die beiden verbleibenden visuellen Klassen unterscheiden sich von den oben genannten, da sie die Pixelwerte in drei Teile aufteilen und drei separate Tabellen für die Intensität von Rot, Grün und Blau verwenden. Entsprechend dieser Farbdarstellung wird ein Pixelwert wie folgt in ein RGB-Tripel umgewandelt:

  1. Der Pixelwert wird als eine Folge von Bits gesehen
  2. Diese Sequenz besteht aus drei Teilen
  3. Jeder dieser drei Bitblöcke wird als Ganzzahl betrachtet und als Index verwendet, um einen Wert in jeder der drei separaten Tabellen zu finden

Für diesen Mechanismus muss die Farbkarte aus drei separaten Tabellen bestehen, eine für jede Primärfarbe . Das Ergebnis der Umwandlung ist immer noch ein Dreifach der Intensitätswerte. Die visuellen Klassen, die diese Darstellung verwenden, sind die DirectColor und TrueColor diejenigen, die sich darin unterscheiden, ob der Client Farbkarten ändern kann oder nicht.

Diese sechs Mechanismen zur Darstellung von Farben mit Pixelwerten erfordern einige zusätzliche Parameter, um zu funktionieren. Diese Parameter werden in einem visuellen Typ zusammengefasst , der eine visuelle Klasse und andere Parameter für die Darstellung von Farben enthält. Jeder Server verfügt über einen festen Satz von visuellen Typen, die jeweils einer numerischen Kennung zugeordnet sind. Diese Bezeichner sind vorzeichenlose 32-Bit-Ganzzahlen, unterscheiden sich jedoch nicht unbedingt von Bezeichnern von Ressourcen oder Atomen.

Wenn die Verbindung von einem Client akzeptiert wird, enthält das vom Server gesendete Akzeptanzpaket eine Folge von Blöcken, die jeweils Informationen zu einem einzelnen Bildschirm enthalten. Für jeden Bildschirm enthält der relative Block eine Liste anderer Blöcke, die sich jeweils auf eine bestimmte Farbtiefe beziehen, die vom Bildschirm unterstützt wird. Für jede unterstützte Tiefe enthält diese Liste eine Liste von visuellen Typen. Infolgedessen ist jedem Bildschirm eine Anzahl möglicher Tiefen zugeordnet, und jeder Tiefe jedes Bildschirms ist eine Anzahl möglicher visueller Typen zugeordnet. Ein bestimmter visueller Typ kann für mehr Bildschirme und für verschiedene Tiefen verwendet werden.

Für jeden visuellen Typ enthält das Akzeptanzpaket sowohl seine Kennung als auch die darin enthaltenen tatsächlichen Parameter (visuelle Klasse usw.). Der Client speichert diese Informationen, da er sie anschließend nicht anfordern kann. Darüber hinaus können Clients keine neuen visuellen Typen ändern oder erstellen. Anforderungen zum Erstellen eines neuen Fensters umfassen die Tiefe und die Kennung des visuellen Typs, der zur Darstellung der Farben dieses Fensters verwendet werden soll.

Farbkarten werden unabhängig davon verwendet, ob die den Bildschirm steuernde Hardware (z. B. eine Grafikkarte ) eine Palette verwendet , bei der es sich um eine Tabelle handelt, die auch zur Darstellung von Farben verwendet wird. Server verwenden Farbkarten, auch wenn die Hardware keine Palette verwendet. Immer wenn die Hardware Paletten verwendet, kann nur eine begrenzte Anzahl von Farbkarten installiert werden. Insbesondere wird eine Farbkarte installiert, wenn die Hardware entsprechende Farben anzeigt. Ein Client kann den Server auffordern, eine Farbkarte zu installieren. Dies kann jedoch die Deinstallation eines anderen colormap erfordern: der Effekt ist , dass Windows die deinstallierte colormap verwendet nicht mit der richtigen Farbe, ein Effekt genannt gezeigt Farbe blinkt oder Technicolor . Dieses Problem kann mithilfe von Standard-Farbkarten gelöst werden , bei denen es sich um Farbkarten mit einer vorhersagbaren Zuordnung zwischen Pixelwerten und Farben handelt. Dank dieser Eigenschaft können Standard-Farbkarten von verschiedenen Anwendungen verwendet werden.

Die Erstellung von Farbkarten wird durch die ICCCM- Konvention geregelt . Standard-Farbkarten werden durch das ICCCM und die Xlib- Spezifikation geregelt .

Ein Teil des X-Farbsystems ist das X-Farbmanagementsystem (xcms). Dieses System wurde 1991 mit X11R6 Release 5 eingeführt. Dieses System besteht aus mehreren zusätzlichen Funktionen in xlib, die in der Funktionsreihe Xcms * enthalten sind. Dieses System definiert geräteunabhängige Farbschemata, die in geräteabhängige RGB-Systeme umgewandelt werden können. Das System besteht aus den xlib Xcms * -Funktionen und der X Device Color Characterization Convention (XDCCC), die beschreibt, wie die verschiedenen geräteunabhängigen Farbsysteme in geräteabhängige RGB-Farbsysteme konvertiert werden. Dieses System unterstützt die Farbsysteme CIEXYZ , xyY , CIELUV und CIELAB sowie die Farbsysteme TekHVC . [1] , [2]

Atome

Atome sind 32-Bit-Ganzzahlen, die Zeichenfolgen darstellen . Die Protokolldesigner haben Atome eingeführt, weil sie Zeichenfolgen in einer kurzen und festen Größe darstellen: Während eine Zeichenfolge beliebig lang sein kann, ist ein Atom immer eine 32-Bit-Ganzzahl. Die Atom-Kürze wurde ausgenutzt, indem ihre Verwendung in den Arten von Paketen vorgeschrieben wurde, die wahrscheinlich viele Male mit denselben Zeichenfolgen gesendet werden. Dies führt zu einer effizienteren Nutzung des Netzwerks. Die feste Größe von Atomen wurde ausgenutzt, indem eine feste Größe für Ereignisse angegeben wurde, nämlich 32 Bytes: Pakete mit fester Größe können Atome enthalten, während sie keine langen Zeichenfolgen enthalten können.

Atome sind genau Bezeichner von Zeichenfolgen, die auf dem Server gespeichert sind. Sie ähneln den Kennungen von Ressourcen (Windows, Pixmaps usw.), unterscheiden sich jedoch in zweierlei Hinsicht von ihnen. Zunächst werden die Kennungen der Atome vom Server und nicht vom Client ausgewählt. Mit anderen Worten, wenn ein Client die Erstellung eines neuen Atoms anfordert, sendet er dem Server nur die zu speichernde Zeichenfolge, nicht deren Kennung. Diese Kennung wird vom Server ausgewählt und als Antwort an den Client zurückgesendet. Der zweite wichtige Unterschied zwischen Ressourcen und Atomen besteht darin, dass Atome nicht mit Clients assoziiert sind. Einmal erstellt, überlebt ein Atom, bis der Server beendet oder zurückgesetzt wird (dies ist nicht das Standardverhalten von Ressourcen).

Atome sind Identifikatoren und daher eindeutig. Ein Atom und eine Ressourcenkennung können jedoch zusammenfallen. Die einem Atom zugeordnete Zeichenfolge wird als Atomname bezeichnet . Der Name eines Atoms kann nach der Erstellung nicht geändert werden, und keine zwei Atome können denselben Namen haben. Infolgedessen wird der Name eines Atoms üblicherweise verwendet, um das Atom anzugeben: "das Atom ABCD " bedeutet genauer "das Atom, dessen zugehöriger String" ist ABCD . oder "das Atom, dessen Name ist ABCD ." Ein Client kann die Erstellung eines neuen Atoms anfordern und das Atom (den Bezeichner) einer bestimmten Zeichenfolge anfordern. Einige Atome sind vordefiniert (vom Server mit der angegebenen Kennung und Zeichenfolge erstellt).

Atome werden für eine Reihe von Zwecken verwendet, hauptsächlich im Zusammenhang mit der Kommunikation zwischen verschiedenen Clients, die mit demselben Server verbunden sind. Insbesondere werden sie in Verbindung mit den Eigenschaften von Fenstern verwendet, die nachstehend beschrieben werden.

Die Liste aller Atome auf einem Server kann mit dem Programm ausgedruckt werden xlsatoms . Insbesondere druckt dieses Programm jedes Atom (den Bezeichner, dh eine Zahl) mit seinem Namen (der zugehörigen Zeichenfolge).

Eigenschaften

Jedes Fenster verfügt über eine vordefinierte Reihe von Attributen und Eigenschaften, die alle auf dem Server gespeichert sind und über entsprechende Anforderungen für die Clients zugänglich sind. Attribute sind Daten über das Fenster, wie z. B. Größe, Position, Hintergrundfarbe usw. Eigenschaften sind beliebige Daten, die an ein Fenster angehängt werden. Im Gegensatz zu Attributen haben Eigenschaften auf der Ebene des X Window-Kernprotokolls keine Bedeutung. Ein Client kann beliebige Daten in einer Eigenschaft eines Fensters speichern.

Eine Eigenschaft ist durch einen Namen, einen Typ und einen Wert gekennzeichnet. Eigenschaften ähneln Variablen in imperativen Programmiersprachen , da ein Client eine neue Eigenschaft mit einem bestimmten Namen und Typ erstellen und einen Wert darin speichern kann. Windows sind Eigenschaften zugeordnet: Zwei Eigenschaften mit demselben Namen können in zwei verschiedenen Fenstern mit unterschiedlichen Typen und Werten vorhanden sein.

Name, Typ und Wert einer Eigenschaft sind Zeichenfolgen. Genauer gesagt handelt es sich um Atome, dh auf dem Server gespeicherte Zeichenfolgen, auf die die Clients über Bezeichner zugreifen können. Eine Clientanwendung kann auf eine bestimmte Eigenschaft zugreifen, indem sie die Kennung des Atoms verwendet, das den Namen der Eigenschaft enthält.

Eigenschaften werden hauptsächlich für die Kommunikation zwischen Clients verwendet. Beispielsweise wird die benannte Eigenschaft WM_NAME (die Eigenschaft, die von dem Atom benannt wird, dessen zugehörige Zeichenfolge lautet "WM_NAME" ) zum Speichern des Fensternamens verwendet. Fenstermanager lesen diese Eigenschaft normalerweise, um den Namen der Fenster in ihrer Titelleiste anzuzeigen.

Einige Arten der Kommunikation zwischen Clients verwenden die Eigenschaften des Stammfensters. Gemäß der Freedesktop- Fenstermanager-Spezifikation sollten Fenstermanager beispielsweise die Kennung des aktuell aktiven Fensters in der Eigenschaft _NET_ACTIVE_WINDOW des Stammfensters speichern . Die X-Ressourcen , die Parameter von Programmen enthalten, werden auch in den Eigenschaften des Stammfensters gespeichert. Auf diese Weise können alle Clients auf sie zugreifen, auch wenn sie auf verschiedenen Computern ausgeführt werden.

Das xprop Programm druckt die Eigenschaften eines bestimmten Fensters. xprop -root Gibt den Namen, den Typ und den Wert jeder Eigenschaft des Stammfensters aus.

Zuordnungen

Dieser Schlüssel erzeugt immer den gleichen Tastencode , aber die Symbole / , 7 und { sind auf drei verschiedenen zugehörigen Keysyms .

Im X - Window - System, jeder einzelne ist physische Taste , um eine Zahl im Bereich 8-255, assoziiert sein benanntes Keycode . Ein Schlüsselcode identifiziert nur einen Schlüssel, nicht ein bestimmtes Zeichen oder einen bestimmten Begriff (z. B. "Bild auf") unter denjenigen, die auf den Schlüssel gedruckt werden können. Jedes dieser Zeichen oder Begriffe wird stattdessen durch ein Schlüsselsymbol gekennzeichnet . Während ein Schlüsselcode nur von der tatsächlich gedrückten Taste abhängt, kann ein Keysym beispielsweise davon abhängen, ob die Umschalttaste oder ein anderer Modifikator ebenfalls gedrückt wurde.

Wenn eine Taste gedrückt oder losgelassen wird, sendet der Server Ereignisse vom Typ KeyPress oder KeyRelease an die entsprechenden Clients. Diese Ereignisse enthalten:

  1. der Schlüsselcode der gedrückten Taste
  2. den aktuellen Status der Modifikatoren (Shift, Control usw.) und Maustasten
Übersetzung vom Schlüsselcode zum Schlüsselsym.

Der Server sendet daher den Schlüsselcode und den Modifikatorstatus, ohne zu versuchen, sie in ein bestimmtes Zeichen zu übersetzen. Es liegt in der Verantwortung des Kunden, diese Konvertierung durchzuführen. Beispielsweise kann ein Client ein Ereignis erhalten, das besagt, dass eine bestimmte Taste gedrückt wurde, während der Shift-Modifikator gedrückt war. Wenn dieser Schlüssel normalerweise das Zeichen "a" erzeugen würde, ordnet der Client (und nicht der Server) dieses Ereignis dem Zeichen "A" zu.

Während die Übersetzung von Schlüsselcodes zu Keysyms vom Client durchgeführt wird, wird die Tabelle, die diese Zuordnung darstellt, vom Server verwaltet. Durch das Speichern dieser Tabelle an einem zentralen Ort ist sie für alle Clients zugänglich. Typische Clients fordern diese Zuordnung nur an und verwenden sie zum Dekodieren des Keycode- und Modifikatorfelds eines Schlüsselereignisses in ein Keysym. Clients können diese Zuordnung jedoch auch nach Belieben ändern.

Ein Modifikator ist eine Taste, die beim Drücken die Interpretation anderer Tasten ändert. Ein üblicher Modifikator ist die Umschalttaste : Wenn die Taste, die normalerweise ein "a" in Kleinbuchstaben erzeugt, zusammen mit der Umschalttaste gedrückt wird, wird ein "A" in Großbuchstaben erzeugt. Andere gängige Modifikatoren sind "Control", "Alt" und "Meta".

Der X-Server arbeitet mit höchstens acht Modifikatoren. Jeder Modifikator kann jedoch mehreren Schlüsseln zugeordnet werden. Dies ist erforderlich, da viele Tastaturen für einige Modifikatoren doppelte Tasten haben. Beispielsweise verfügen viele Tastaturen über zwei Umschalttasten (eine links und eine rechts). Diese beiden Tasten erzeugen beim Drücken zwei unterschiedliche Tastencodes, aber der X-Server ordnet beide dem Modifikator "Shift" zu.

Für jeden der acht Modifikatoren verwaltet der X-Server eine Liste der Schlüsselcodes, die er als diesen Modifikator betrachtet. Wenn beispielsweise die Liste des ersten Modifikators (der Modifikator "Shift") 0x37 den Schlüsselcode enthält , wird der Schlüssel, der den Schlüsselcode erzeugt, 0x37 vom X-Server als Shift-Schlüssel betrachtet.

Die Liste der Modifikatorzuordnungen wird vom X-Server verwaltet, kann jedoch von jedem Client geändert werden. Beispielsweise kann ein Client anfordern, dass die " F1-Taste " zur Liste der "Shift" -Modifikatoren hinzugefügt wird. Ab diesem Zeitpunkt verhält sich diese Taste wie ein anderer Shift-Modifikator. Der Schlüsselcode für F1 wird jedoch weiterhin generiert, wenn diese Taste gedrückt wird. Infolgedessen funktioniert F1 wie zuvor (zum Beispiel kann ein Hilfefenster geöffnet werden, wenn es gedrückt wird), funktioniert aber auch wie die Umschalttaste (Drücken von "a" in einem Texteditor, während F1 gedrückt ist, fügt "A" hinzu). zum aktuellen Text).

Der X-Server verwaltet und verwendet eine Modifikatorzuordnung für die Maustasten. Die Schaltflächen können jedoch nur permutiert werden . Dies ist vor allem nützlich, um die Schaltfläche ganz links und ganz rechts gegen Linkshänder auszutauschen .

Das xmodmap Programm zeigt und ändert die Tasten-, Modifikator- und Maustastenzuordnungen.

Grabs

Ein Grab ist eine Bedingung, bei der alle Tastatur- oder Mausereignisse an einen einzelnen Client gesendet werden. Ein Client kann einen Zugriff auf die Tastatur, die Maus oder beides anfordern: Wenn die Anforderung vom Server erfüllt wird, werden alle Tastatur- / Mausereignisse an den Greifclient gesendet, bis der Zugriff freigegeben wird. Die anderen Clients erhalten diese Ereignisse nicht.

Wenn ein Client ein Grab anfordert, gibt er ein Grab-Fenster an : Alle Ereignisse werden an den Grabbing-Client gesendet, als wären sie relativ zum Grab-Fenster. Die anderen Clients erhalten jedoch keine Ereignisse, selbst wenn sie diese im Grab-Fenster ausgewählt haben. Es gibt zwei Arten von Greifern:

  • aktiv: Der Greifer erfolgt sofort
  • passiv: Der Greifer findet nur statt, wenn eine zuvor angegebene Taste oder Maustaste gedrückt wird, und endet, wenn er losgelassen wird
Wenn der Zeiger oder die Tastatur eingefroren sind, werden die von ihnen erzeugten Ereignisse in einer Warteschlange blockiert. Wenn sie erfasst werden, werden ihre Ereignisse an den abrufenden Client anstatt an das Fenster umgeleitet, in dem sie normalerweise empfangen werden. Zeigerereignisse können abhängig von einer Ereignismaske verworfen werden.

Ein Client kann die Tastatur, den Zeiger oder beides erfassen. Eine Anforderung zum Greifen kann eine Anforderung zum Einfrieren der Tastatur oder des Zeigers enthalten. Der Unterschied zwischen Greifen und Einfrieren besteht darin, dass das Ergreifen den Empfänger von Ereignissen ändert, während das Einfrieren die Zustellung insgesamt stoppt. Wenn ein Gerät eingefroren ist, werden die von ihm erzeugten Ereignisse in einer Warteschlange gespeichert, die wie gewohnt zugestellt wird, wenn das Einfrieren beendet ist.

Bei Zeigerereignissen wirkt sich ein zusätzlicher Parameter auf die Übermittlung von Ereignissen aus: eine Ereignismaske, die angibt, welche Arten von Ereignissen übermittelt und welche verworfen werden sollen.

Die Anforderungen für das Abrufen enthalten ein Feld, in dem angegeben wird, was mit Ereignissen geschieht, die an den Abruf-Client gesendet werden, selbst wenn der Abruf nicht eingerichtet wurde. Insbesondere kann der Kunde verlangen, dass sie wie gewohnt oder entsprechend dem Zugriff gesendet werden. Diese beiden Bedingungen sind nicht dieselben, wie sie erscheinen mögen. Beispielsweise kann ein Client, der normalerweise die Tastaturereignisse in einem ersten Fenster empfängt, anfordern, dass die Tastatur von einem zweiten Fenster erfasst wird. Ereignisse, die normalerweise an das erste Fenster gesendet werden, können abhängig vom Parameter in der Grab-Anforderung zum Grab-Fenster umgeleitet werden oder nicht.

Ein Client kann auch den Zugriff auf den gesamten Server anfordern. In diesem Fall wird keine Anforderung vom Server verarbeitet, außer denjenigen, die vom Grabbing-Client stammen.

Andere

Andere Anforderungen und Ereignisse im Kernprotokoll sind vorhanden. Die erste Art von Anforderungen bezieht sich auf die übergeordnete Beziehung zwischen Fenstern: Ein Client kann anfordern, das übergeordnete Element eines Fensters zu ändern, oder Informationen zur Elternschaft von Fenstern anfordern. Andere Anforderungen beziehen sich auf die Auswahl , die jedoch hauptsächlich von anderen Protokollen geregelt wird. Andere Anforderungen betreffen den Eingabefokus und die Form des Zeigers . Ein Client kann auch verlangen, dass der Eigentümer einer Ressource (Fenster, Pixmap usw.) beendet wird, wodurch der Server die Verbindung zu dieser Ressource beendet. Schließlich kann ein Client eine Anforderung ohne Operation an den Server senden .

Erweiterungen

Die Form Erweiterung ermöglicht oclock zu einem runden Fenster zu erstellen.

Das X Window-Kernprotokoll wurde so konzipiert, dass es erweiterbar ist. Das Kernprotokoll gibt einen Mechanismus zum Abfragen der verfügbaren Erweiterungen und zum Erstellen von Erweiterungsanforderungen, Ereignissen und Fehlerpaketen an.

Insbesondere kann ein Client die Liste aller verfügbaren Erweiterungen für Daten in Bezug auf eine bestimmte Erweiterung anfordern. Die Erweiterungspakete ähneln den Paketen des Kernprotokolls. Das Kernprotokoll gibt an, dass Anforderungs-, Ereignis- und Fehlerpakete eine Ganzzahl enthalten, die ihren Typ angibt (z. B. ist die Anforderung zum Erstellen eines neuen Fensters mit 1 nummeriert). Ein Bereich dieser Ganzzahlen ist für Erweiterungen reserviert.

Genehmigung

Hauptartikel: X Window-Autorisierung

Wenn der Client zum ersten Mal eine Verbindung mit dem Server herstellt, kann der Server antworten, indem er die Verbindung entweder akzeptiert, ablehnt oder eine Authentifizierung anfordert . Eine Authentifizierungsanforderung enthält den Namen der zu verwendenden Authentifizierungsmethode. Das Kernprotokoll gibt den Authentifizierungsprozess nicht an, der von der Art der verwendeten Authentifizierung abhängt, außer dass der Server entweder ein Akzeptanz- oder ein Ablehnungspaket sendet.

Während der regulären Interaktion zwischen einem Client und einem Server beziehen sich die einzigen Anforderungen im Zusammenhang mit der Authentifizierung auf die hostbasierte Zugriffsmethode . Insbesondere kann ein Client die Aktivierung dieser Methode anfordern und das Lesen und Ändern der Liste der Hosts ( Clients ) anfordern , die zur Verbindung berechtigt sind. Typische Anwendungen verwenden diese Anforderungen nicht. Sie werden vom xhost Programm verwendet, um einem Benutzer oder einem Skript Zugriff auf die Hostzugriffsliste zu gewähren. Die hostbasierte Zugriffsmethode wird als unsicher angesehen.

Xlib und andere Client-Bibliotheken

Hauptartikel: Xlib

Die meisten Client-Programme kommunizieren über die Xlib- Client-Bibliothek mit dem Server . Insbesondere verwenden die meisten Clients Bibliotheken wie Xaw , Motif , GTK + oder Qt, die wiederum Xlib für die Interaktion mit dem Server verwenden. Die Verwendung von Xlib hat folgende Auswirkungen:

  1. Xlib macht den Client in Bezug auf Antworten und Ereignisse synchron:
    1. Die Xlib-Funktionen, die Anforderungen senden, blockieren, bis die entsprechenden Antworten, falls vorhanden, empfangen werden. Mit anderen Worten, ein X Window-Client, der Xlib nicht verwendet, kann eine Anforderung an den Server senden und dann andere Vorgänge ausführen, während er auf die Antwort wartet. Ein Client, der Xlib verwendet, kann jedoch nur eine Xlib-Funktion aufrufen, die die Anforderung sendet und auf die Antwort wartet. Dadurch wird der Client blockiert, während auf die Antwort gewartet wird (es sei denn, der Client startet einen neuen Thread, bevor er die Funktion aufruft).
    2. Während der Server Ereignisse asynchron sendet , speichert Xlib vom Client empfangene Ereignisse in einer Warteschlange . Das Client-Programm kann nur auf sie zugreifen, indem es explizit Funktionen der X11-Bibliothek aufruft. Mit anderen Worten, der Client muss blockieren oder warten, wenn er ein Ereignis erwartet.
  2. Xlib sendet Anforderungen nicht sofort an den Server, sondern speichert sie in einer Warteschlange, die als Ausgabepuffer bezeichnet wird . Die Anforderungen im Ausgabepuffer werden tatsächlich gesendet, wenn:
    1. Das Programm fordert dies explizit an, indem es eine Bibliotheksfunktion aufruft, wie z XFlush .
    2. Das Programm ruft eine Funktion auf, die als Ergebnis eine Antwort vom Server enthält, z XGetWindowAttributes .
    3. Das Programm fragt nach einem Ereignis in der Ereigniswarteschlange (z. B. durch Aufrufen XNextEvent ) und den Aufrufblöcken (z. B. XNextEvent blockiert, wenn die Warteschlange leer ist.)

Übergeordnete Bibliotheken wie Xt (das wiederum von Xaw und Motif verwendet wird ) ermöglichen es dem Client-Programm, die mit einigen Ereignissen verbundenen Rückruffunktionen anzugeben . Die Bibliothek kümmert sich darum, die Ereigniswarteschlange abzufragen und bei Bedarf die entsprechende Funktion aufzurufen. Einige Ereignisse, z. B. solche, die darauf hinweisen, dass ein Fenster neu gezeichnet werden muss, werden intern von Xt behandelt.

Bibliotheken niedrigerer Ebenen, wie z. B. XCB , bieten asynchronen Zugriff auf das Protokoll und ermöglichen so ein besseres Ausblenden der Latenz.

Nicht spezifizierte Teile

Das X Window System-Kernprotokoll schreibt keine Kommunikation zwischen Clients vor und legt nicht fest, wie Fenster zur Bildung der visuellen Elemente verwendet werden, die in grafischen Benutzeroberflächen ( Schaltflächen , Menüs usw.) üblich sind. Grafische Elemente der Benutzeroberfläche werden von Clientbibliotheken definiert, die Widget-Toolkits realisieren . Die Kommunikation zwischen Clients wird durch andere Standards wie die ICCCM- und Freedesktop- Spezifikationen abgedeckt .

Die Kommunikation zwischen Clients ist relevant für Auswahlen, Pufferausschnitte und Drag & Drop . Dies sind die Methoden, mit denen ein Benutzer Daten von einem Fenster in ein anderes überträgt. Da die Fenster von verschiedenen Programmen gesteuert werden können, ist ein Protokoll zum Austausch dieser Daten erforderlich. Inter-Client - Kommunikation ist auch für X Window - Manager , die sind Programme , die das Aussehen der Fenster und die allgemeine Kontrolle Look-and-Feel von der grafischen Benutzeroberfläche. Ein weiteres Problem, bei dem die Kommunikation zwischen Clients in gewissem Maße relevant ist, ist das Sitzungsmanagement .

Der Start einer Benutzersitzung ist ein weiteres Problem, das vom Kernprotokoll nicht abgedeckt wird. Normalerweise wird dies automatisch vom X-Display-Manager durchgeführt . Der Benutzer kann jedoch auch eine Sitzung manuell starten, in der die Programme xinit oder startx ausgeführt werden.

Siehe auch

Verweise

Externe Links