 |
Das X Window System
Der NameFast jeder sagt "X-Windows", dieser Name ist jedoch nicht korrekt. Das X Consortium hat die folgenden Namen als richtig festgelegt:- X
- X Window System
- X Version 11
- X Window System, Version 11
- X11
Das X Window System
X begann als Protokollspezifikation. Nachdem vor einigen
Jahren immer schnellere Rechner mit Bitmap-Grafikdisplays erhältlich waren,
ging das MIT mit der Unterstützung von einigen Firmen (dem X Consortium)
daran, das Windowsystem für die Zukunft zu spezifizieren. Es wurde dabei
zuerst ein Protokoll festgelegt. Danach begann das MIT mit einer
Beispielimplementierung des Protokolls, um zu zeigen, wie es funktioniert und welche
Möglichkeiten es bietet. Nach einigen Jahren begannen dann Firmen mit dem
Vertrieb von kommerziellen Implementierungen des X Protokolls.
Da das Protokoll allerdings recht aufwendig war - es teilt sich der Klarheit
wegen in mehrere streng getrennte Schichten - waren die anfänglichen
Implementierungen relativ langsam. Wesentlich langsamer jedenfalls als solche
Windowsysteme, die direkt auf das Bitmap-Display zugreifen. Es folgten dann
immer mehr Programme, die auf dem X Window System aufbauen.
Das X Window System ist jedoch keine einheitliche Benutzeroberfläche, die ein
bestimmtes "Look-and-Feel" bietet. X könnte aussehen wie der Macintosh
Finder oder wie Microsoft Windows. Dieses deshalb, weil das X-Protokoll
sehr einfach ist. Man kann lediglich grafische Elemente (Linien, Kreise, etc.)
und Buchstaben auf dem Bildschirm anzeigen.
Das Protokoll enthält keine komplexeren Grafikelemente wie Buttons oder Menus.
Deshalb gibt es auch keine Aussagen über Aussehen von Anwendungsprogrammen
(Style Guide), so daß sich mehrere Standards gebildet haben.
Möchte man zum Beispiel einen Knopf (Button) mit einer Aufschrift, so muß
dieser aus Linien und Text selbst zusammengesetzt werden. Dies kann dem
Programmierer aber auch durch ein Toolkit abgenommen werden. Diese Toolkits
bestimmen dann hauptsächlich das Look-and-Feel.
Komponenten von X
X benötigt hardwareseitig ein Bitmap-Display, eine Tastatur und
ein Pointing-Device (Maus, Grafiktablett, etc.)
Das Pointing-Device muß nur zum Zeigen auf Punkte fähig sein.
Es könnte zum Beispiel auch ein Touch-Screen sein. Oder eine
Maus mit nur einer Taste. Soll ein Programm konform
zur X-Spezifikation sein, müssen alle Funktionen mit
nur einer Maustaste ausführbar sein. Dies kann man z. B.
erreichen, indem man beim Drücken der Maustaste auch noch
gleichzeitig gedrückte Tasten (Control, Meta, etc.) abfragt.
Softwareseitig gibt es folgende Prozesse:
| X Server |
Der X-Server ist das Programm, das alle Bildschirmausgaben übernimmt und
alle Eingaben von der Tastatur und der Maus verarbeitet. Daher ist ein Teil des
X-Servers sehr an die Hardware des Rechners gebunden (Farb- oder
Schwarzweiß-Bildschirm, Art der Tastatur, Anzahl der Maustasten,
Bildschirmgröße ...). Ein Programm, das etwas auf dem Bildschirm
ausgeben will, schickt einen diesbezüglichen Auftrag an den X-Server, der
daraufhin eine Linie zeichnet, einen Text ausgibt oder tut, was immer das
Programm von ihm verlangt. In der anderen Richtung gibt der X-Server Meldungen
an die X-Clients, wann immer der Benutzer eine Eingabe getätigt hat, sei es
das Bewegen der Maus, das Drücken einer Maustaste oder eine Eingabe
über die Tastatur. Die Programme können dann entscheiden, was sie mit
dieser Eingabe anfangen und wie (oder ob überhaupt) sie darauf reagieren.
Vorteil dieser Konfiguration ist, daß nur der X-Server über die
Möglichkeiten der vorhandenen Hardware informiert sein muß. Die Clients
können diese Information vom Server erfragen, wenn sie sie brauchen,
müssen sich ansonsten aber nicht darum kümmern.
Zur Verdeutlichung noch ein Hinweis: bei den meisten anderen Client-Server Systemen
(beispielsweise Datenbanksystem, Mailsystem usw.) befindet sich der
Client näher am Benutzer als der Server. Bei X ist das naturgemäß
umgekehrt, da der Server Tastatur und Bildschirm verwaltet und den
Clients zur Verfügung stellt.
|
|---|
| X Clients |
Jedes Programm, das auf einem X-Bildschirm ein Fenster darstellen will, ist ein
X-Client. Der X-Client bittet den Server, gewisse Aufgaben (eben das Zeichnen
des Fensters) für ihn zu übernehmen. Sie müssen dazu Aufträge
im X Protokoll an den Server schicken.
|
|---|
| Window-Manager |
Ein Client hat den anderen gegenüber einen gewissen Sonderstatus: der
Window-Manager, hier heißt er ctwm. Er stellt dem Benutzer Mittel
zur Verfügung, mit deren Hilfe dieser das Aussehen seiner
Benutzeroberfläche bestimmen kann. Insbesondere kann der Window-Manager die
Größe und die Position der Fenster anderer Clients beeinflussen. Die
Clients können dem Window-Manager Hinweise geben, wo und in welcher
Größe sie ihre Fenster plaziert haben wollen. Der Window-Manager
muß diese Hinweise zwar nicht berücksichtigen, die meisten gängigen
Systeme tun dies aber. Durch die Funktion des Window-Managers ergibt sich,
daß es zumindest problematisch ist, zwei Window-Manager für einen
Bildschirm zu starten. Daher prüfen Window-Manager beim Start in der Regel,
ob bereits ein anderer Window-Manager für den Bildschirm existiert und
brechen in diesem Fall die Arbeit ab.
Die Rahmen und Titelbalken, die die einzelnen Fenster verzieren, sind
nicht Teil des jeweiligen Clients, sondern werden vom Windowmanager um
die Fenster herumgezeichnet, damit durch ihre Betätigung Funktionen des
Windowmanagers ausgelöst werden können.
Der Windowmanager bestimmt somit auch "look-and-feel" der Benutzeroberfläche.
Beachten Sie aber, daß der Window-Manager aber auch nur ein
Clientprozeß ist. Es gibt alle möglichen Window-Manager:
| vtwm | Virtual twm (virtueller Screen mit Window) |
| gwm | Generic Window Manager (gut konfigurierbar) |
| olwm | OPEN LOOK Window Manager |
| mwm | Motif Window Manager |
| ... | Und viele andere |
|
|---|
Was ist das Besondere an X?
X ist ein portables Windowsystem. X benötigt nur Benutzerprozeße und keine
Veränderungen am Betriebssystemkern. X-Server gibt es auch auf anderen
Betriebssystemen (MS-DOS, MacOS, Atari TOS, Windows etc.) und es gibt sogenannte
X-Terminals, intelligente Grafikterminals, die einen integrierten X Server haben.
X ist netzwerkfähig. Clients können ihre Grafikausgabe auch auf Server
machen, die auf anderen Rechnern im Netz laufen. Als Netzwerkprotokolle können
dabei verschiedene Protokolle eingesetzt werden. Bei Unix ist dies meist
TCP/IP.
Wie benutzt man X über ein Netzwerk
Das X Protokoll unterstützt ja auch Rechner, die vernetzt sind. Das bedeutet,
man kann Ausgaben von einem Client auf Rechner A auch auf einem Server auf
Rechner B ausgeben. Dafür ist folgendes notwendig:
Auf dem Zielrechner muß dem Server mitgeteilt werden, daß er Requests
vom Senderechner zulassen darf. Das geschieht mit dem Kommando:
xhost +senderechner
Auf dem Senderechner muß man dem Client mitteilen, daß die Ausgabe nicht
auf dem eigenen Display erscheinen soll, sondern beim Zielrechner. Dazu setzt
man entweder die Environment-Variable
export DISPLAY=zielrechner:0
oder man schreibt beim Aufruf des Programms
clientprogramm -display zielrechner:0
Die Zahl hinter dem Rechnernamen gibt die Nummer des Displays an. Sie kann
auch eine Nachkommastelle haben, z.B. 0.1. Normalerweise haben aber die
Rechner nur ein Display mit der Nummer 0.
Die X Session
Entweder sofort nach dem Einloggen oder durch das Kommando startx wird
für den Benutzer eine Session gestartet. Dabei werden automatisch verschiedene
Clients gestartet (xterm, twm, xclock, etc.). Die Session beendet sich,
wenn der Windowmanager beendet wird.
Der Mechanismus funktioniert folgendermaßen:
von Systemprozessen wird eine Prozedur aufgerufen, welche die
Session steuert. Wenn sich die Prozedur beendet, übernehmen wieder die
Systemprozesse die Steuerung.
process xdm is
while (true)
do
xlogin;
if (Benutzer hat eigene Session-Prozedur)
then fuehre Benutzer-Session-Prozedur aus
else if (Benutzer hat zusätzliche Session-Prozedur)
then fuehre zusätzliche Session-Prozedur im Hintergrund aus
fi;
starte xterm im Hintergrund;
starte xclock im Hintergrund;
starte twm;
fi
done
endprocess
Bei xdm heißt die Benutzer-Session-Prozedur .xsession und die zusätzliche
Session-Prozedur .xsession+. Man sollte darauf achten, daß diese Dateien
ausführbar sind. Außerdem wird die Session beendet, wenn sich die
Prozedur beendet. In der Prozedur sollten also alle Kommandos im Hintergrund
gestartet werden, außer dem letzten, das während der gesamten Session
laufen muß. Dies ist meist der Window-Manager. Wird dieser dann mit Exit
beendet, wird auch die Session mit allen anderen Clients beendet.
Resourcen
X-Clients können durch Resourcen parametrisiert werden. Clients besitzen
Variablen, die zur Kommunikation zwischen Clients dienen. Diese sind die
sogenannten Properties. Eine spezielle Property des Servers sind die
Resources. In ihnen sind Parameter gespeichert, welche Clients abfragen
können. Resourcen sind zum Beispiel geometry oder font.
Resourcen sind hierarchisch aufgebaut. Jedes Programm greift auf eine
Klasse von Resourcen zu (xterm zum Beispiel auf Xterm). Darunter können
sich Komponenten des Programms befinden und am Ende der Hierarchie
stehen Eigenschaften. Teile der Hierarchie können auch durch Wildcards
('*') ersetzt werden. Beispiel:
xterm*font: 9x15
setzt in allen Komponenten von xterm den gewünschten Font auf 9x15.
Resourcen werden vom System vorbesetzt. Man kann sie durch eigene ersetzen
(.xresources) oder erweitern (.xresources+).
X und Sicherheit
Ein Problem von X ist noch die Sicherheit. Zum Beispiel kommt es vor, daß
xterm-Fenster beim Ausloggen nicht geschloßen werden, sondern beim
nächsten Benutzer wieder auf dem Bildschirm erscheinen.
Ein anderes Problem liegt am Konzept des TCP/IP-Protokolls. Da nicht alle
Rechnertypen, die am Internet hängen, das Konzept einer Benutzer-ID haben,
ist diese auch bei TCP/IP nicht vorgesehen. Auf den X-Server kann also
nicht nur der augenblickliche Benutzer der Konsole zugreifen, sondern alle
Benutzer des Rechners. Und das in beliebiger Form. Ein anderer Benutzer
kann zum Beispiel den gesamten Bildschirminhalt überschreiben.
Bei jedem Anmelden an einem Rechner generiert das Programm xdm, das die
Anmeldemaske zur Verfügung stellt, einen Schlüssel und legt ihn in der
Datei .Xauthority im HOME-Verzeichnis des Benutzers ab. Jedes
X-Programm, das der Benutzer dann startet, sucht in dieser Datei nach dem
Schlüssel und gibt ihn dem Server beim Aufbau der Verbindung an. Nur wenn
dieser Schlüssel mit dem übereinstimmt, der beim Login generiert wurde,
wird die Verbindung tatsächlich aufgebaut, ansonsten wird der Aufbauversuch
vom Server zurückgewiesen. Auf diese Art wird verhindert, daß jeder
Benutzer seine Fenster auf den Bildschirm eines anderen Benutzers legen und
diesen dadurch bei seiner Arbeit behindern kann. Voraussetzung für die
Sicherheit des Systems ist natürlich, daß die Rechte für die Datei
.Xauthority richtig gesetzt sind. Nur der Eigentümer der Datei darf
dafür das Lese- und Schreibrecht haben, alle anderen Benutzer nicht einmal
das Leserecht, da sie sonst den Schlüssel aus der Datei herauslesen
könnten.
X ermöglicht unter anderem jedem Programm, das eine Verbindung zum X-Server
aufbauen kann, das Mitlesen von Tastatureingaben, die auf dem Rechner
vorgenommen werden. Darunter können natürlich auch Paßworteingaben
sein (zum Beispiel bei einem rlogin). Daher darf der Zugriff auf den
Server auf keinen Fall unkontrolliert freigegeben werden.
Der Terminalemulator xterm
Um Nicht-X-Programme unter X laufen lassen zu können, gibt es den
Terminalemulator xterm. Er erzeugt ein Fenster, das sich wie der normale
Textbildschirm an einem UNIX-Rechner verhält. Um die Nutzung optimal zu
gestalten, können mit dem Aufruf mehrere Optionen eingestellt werden, von
denen einige hier aufgeführt werden (Vollständig sind sie in der
Manualseite aufgeführt):
xterm [Optionen]
oder
xterm [Optionen] & (als Hintergrundprozeß)
Optionen:
-e name [parameter]:
Das Programm name wird sofort ausgeführt, wenn sich das Fenster
öffnet. Am Ende des Programms wird das Fenster wieder geschlossen. Die
angegebenen Parameter werden dem Programm übergeben. Der Fenstertitel und
Iconname heißen dann auch name (soweit keine Option -T oder
-n verwendet wurde).
Die Option muß als letzte in der Optionenfolge eingegeben werden, da
alles, was der gesamte Zeilenrest als Teil des auszuführenden Befehls
betrachtet wird! Beispiel:
xterm -e vi main.c
- -l:
Jede Ausgabe in xterm wird in der Datei XtermLog.nnnn
(nnnn entspricht der Prozeßnummer)
abgespeichert und gleichzeitig im Fenster angezeigt.
- +l:
Kein Logging.
- -lf Dateiname:
Die Logging-Ausgabe wird in der Datei Dateiname abgelegt.
- -sb:
Erzeugt den Scroll-Balken am linken Fensterrand.
- +sb:
Kein Scroll-Balken.
- -sl nn:
nn gibt an, wieviele Zeilen nach dem Herausrollen aus dem
Anzeigebereich gespeichert werden sollen. Voreinstellung: 64 Zeilen.
- -T string:
setzt string als Fenstertitel.
- -n string:
setzt string als Fensternamen für den Iconmanager.
- -rv:
Tausche Vordergrund- und Hintergrundfarbe.
- -geometry expression:
gibt an, wie groß das Fenster sein soll und wo es
plaziert werden soll. Das Format für expression:
breite x höhe +xkoord +ykoord
'breite' und 'höhe' geben die Fenstergröße (in Buchstaben) an, 'xkoord'
und 'ykoord' die Position (in Pixeln). Ein xterm-Fenster hat gemäß
Voreinstellung 24 Zeilen mit 80 Zeichen Breite.
Je nach verwendeten Zeichen + oder - ergibt sich die Ecke
des Bildschirms und des Fensters, auf die sich 'xkoord' und 'ykoord' jeweils beziehen.
Es gibt vier Möglichkeiten:
- +0+0 obere, linke Ecke
- -0+0 obere, rechte Ecke
- -0-0 untere, rechte Ecke
- +0-0 untere, linke Ecke
Es kann auch nur die Größe oder nur die
Position angegeben werden. Beispiel:
xterm -geometry 80x25+200+400
- -iconic:
Das aufgerufene Fenster wird sofort iconifiziert. Es erscheint also nur als
Eintrag im Iconmanager (falls vorhanden) und/oder als einzelnes Icon.
Die Datei .xsession
Diese Datei wird nach dem Anmelden vom System abgearbeitet. Es handelt
sich bei ihr um ein Shellscript, das von der Standardshell des
Benutzers. Die Sitzung eines Benutzers dauert so lange, bis die Datei
.xsession vollständig abgearbeitet wurde.
Daraus folgt, daß .xsession mindestens ein Programm nicht als
Hintergrundprozeß starten darf. Das Ende dieses Programms stellt dann
auch das Ende der Sitzung dar.
Es ist sinnvoll, Programmen, die man in .xsession startet,
eine Positionsangabe mitzugeben, entweder direkt oder über .Xdefaults.
Tut man das nicht, muß man das Fenster jeweils per Hand auf dem Bildschirm
positionieren. Das Angeben der Position ist bei vielen Programmen über
den Parameter -geometry möglich. Beispiel:
xterm -geometry 80x25+130+360
erzeugt ein Terminalfenster mit 80 Spalten und 25 Zeilen, dessen obere linke
Ecke an der X-Koordinate 130 und der Y-Koordinate 360 liegt.
Die Datei .xxxwmrc
Diese Datei konfiguriert den Window-Manager (wobei "xxx" für den gewählten
Window-Manager steht. Dieser stellt er die Menüs zur Verfügung, die
erscheinen, wenn man auf dem root-Fenster (dem Bildschirmhintergrund)
die mittlere oder die rechte Maustaste drückt.
Diese Datei dient dazu, die Benutzeroberfläche frei nach seinen eigenen
Wünschen zu gestalten.
Die Datei .rhosts
Diese Datei gibt an, wer sich von welchem Rechner aus ohne Angabe
eines Paßwortes am Rechner anmelden darf. Damit kann man
vermeiden, daß bei jedem Aufruf von rlogin das Paßwort
eingegeben werden muß. .rhosts darf nur für den User selbst
schreibbar sein. Sie muß jedoch für alle lesbar sein. Jede Zeile in
.rhosts muß folgenden Aufbau haben:
Rechnername [Benutzer]
Die Datei .Xdefaults
Viele X-Clients ermöglichen es, ihr Aussehen und ihre Konfiguration mittels
sogenannter Ressourcen festzulegen. Ressourcen sind im Grunde nur
Wörter oder Zeichenketten, die der X-Server bereithält und die der
X-Client bei Bedarf abfragen kann. Meist erkundigt sich der Client beim Server,
ob für ihn Ressourcen definiert sind und verwendet diese, falls es welche
gibt.
Ansonsten benutzt er Standardwerte. Jeder Benutzer kann seine eigenen
Ressourcedefinitionen in der Datei .Xdefaults in seinem HOME-Verzeichnis
ablegen. Diese wird, falls vorhanden, automatisch beim Anmelden dem X-Server
bekanntgemacht.
Was kann man nun überhaupt mit Ressourcen festlegen?
Mit Programmname.geometry wird festgelegt, an
welcher Stelle ein Fenster des angegebenen Programms bei dessen Start auf dem
Bildschirm erscheinen soll.
Die Einträge mit den Endungen background und foreground
legen für die entsprechenden Programme Vordergrund- und Hintergrundfarbe
fest. iconic bestimmt, ob ein bestimmtes Programm als Icon (true)
oder als Fenster (false) gestartet wird.
|
|
|
DIENSTE
