| Available Languages: | Deutsch | English | Español | Français | 日本語 (Nihongo) | Português | Русский (Russkiy) | 中文 (简) (Simplified Chinese) | |
Diese Dokument beschreibt, wie man X11 auf Apples Mac OS X und Darwin laufen lässt. Nach einer Einführung wird die Geschichte beschrieben und dann die derzeitige Situation und die X11 Optionen, die zur Verfügung stehen.
Das X Window System Version 11 oder kurz X11 ist ein System für die grafische Darstellung mit einer netzwerktauglichen Klienten-Server-Architektur. Mit X11 können Programme einzelne Pixel, Linien, Texte, Bilder usw. auf einem Bildschirm darstellen. X11 enthält darüber hinaus auch Bibliotheken, um Elemente von Nutzerschnittstellen, wie Schaltknöpfe, Textfelder, usw. darzustellen.
X11 ist quasi das Standard-Grafiksystem in der Unixwelt. Es ist bei Linux, den *BSDs und den meisten kommerziellen Unix-Varianten dabei. Auch die Desktopumgebungen wie CDE, KDE und Gnome bauen auf X11 auf.
Mac OS X ist ein Betriebsystem von Apple. Wie sein Vorläufer (NeXTStep und OpenStep) basiert es auf BSD und ist damit auch eine Unix-Variante. Allerdings hat es sein eigenes System für die grafische Darstellung, namens Quartz. Sein Aussehen und Verhalten wird als Aqua bezeichnet, wobei die beiden Namen oft wechselseitig verwendet werden.
Darwin ist die "abgespeckte" Version von Mac OS X, kostenlos und mit komplettem Quellcode. Quartz, Aqua und noch einge weitere Technologien gehören nicht dazu und es hat auch nur die Text-Konsole.
XFree86 ist eine Open-Source Implementation von X11. Ursprünglich wurde es für Intel x86 PCs entwickelt. So erhielt es auch seinen Namen. Jetzt läuft es aber auf vielen Architekturen und Betriebsystemen, einschließlich OS/2, Darwin, Mac OS X und Windows.
Die X11-Distributionen von Apple auf OS 10.2, 10.3 und 10.4 leiten sich von XFree86 ab.
X.org ist eine Open-Source Implementation von X11 und der Nachfolger von XFree86 und hat es auch fast überall ersetzt.
Die X11-Distributionen von Apple auf OS 10.5 und 10.6 leiten sich von X.org ab, ebenso XQuartz. Die X11-Distributionen von Apple auf OS 10.7 leitet sich wiederum von XQuartz ab.
XQuartz ist eine X11-Distributionen für OS 10.5 und neuer, das einige Features mehr enthält, als das normale X11 auf 10.5-10.7. Auf 10.5 ersetzt XQuartz die X11-Distribution des Systems, während auf 10.6 and 10.7 Xquartz und die X11-Distribution des Systems koexistieren, indem sie in verschiedenen Pfaden installiert werden. Auf 10.8 ist Xquartz die Standard X11-Distribution.
X11 hat eine Klienten-Server-Architektur. Ein zentrales Program erledigt das tatäschliche Zeichnen und koordiniert den Zugriff von mehreren Programmen - der Server. Ein Programm, das über X11 zeichnen möchte, verbindet sich mit dem Server und teilt ihm mit, was gezeichnet werden soll. Die Programme werden folglich in der X11-Umgebung Klienten genannt.
Bei X11 können Server und Klienten auf verschiedenen Rechnern laufen, wobei es dann häufig zu Missverständnissen kommt. In einer Umgebung mit Arbeitsplatzrechner und Serverrechnern läuft der X11-Display-Server auf dem Arbeitsplatzrechner und das Programm (und damit der Klient) auf dem Serverrechner. Wenn also vom "Server" die Rede ist, geht es um den X11-Display-Server und nicht um den Serverrechner, der im Schrank versteckt ist.
Etwas Hintergrund: X11 modelliert den Bildschirm als eine Hierarchie von Fenster, die sich gegenseitig enthalten. An der Spitze steht ein spezielles Fenster von der Größe des Bildschirms und enthält alle anderen Fenster. Dieses Fenster enthält den Hintergrund und wird Wurzelfenster oder "root window" genannt.
Zurück zum Thema: Wie jede grafische Umgebung wurde X11 so geschrieben, dass es vollständige und ausschließliche Kontrolle über den Bildschirm hat. In Mac OS X hat aber bereits Quartz die Kontrolle über den Bildschirm. Deshalb müssen einige Vorkehrungen getroffen werden, damit die beiden neben einander laufen können.
Eine Variante ist, dass sich die beiden abwechseln. Jede Umgebung hat vollständige Kontrolle über Bildschirm, aber es ist immer nur eine der beiden sichtbar und der Benutzer schaltet zwischen den beiden um. Diese Lösung nennt man Vollbild- oder "rooted" Modus, weil in diesem Modus X11 ein ganz normales Wurzelfenster ("root window") hat, das sich genau wie auf anderen Unix-Systemen verhält.
Die andere Variante ist eine Fenster-für-Fenster-Mischung der beiden Umgebungen. Dadurch muss man nich zwischen den beiden hin und her schalten. Damit gibt es auch kein X11 Wurzelfenster, weil Quartz bereits den Hintergrund verwaltet. Da es kein sichtbares Wurzelfenster gibt, nennt man diesen Modus wurzellos ("rootless"). Dies ist der komfortabelste Modus, um X11 auf Mac OS X zu benutzen.
Bei den meisten grafischen Umgebungen bestimmt das System das Aussehen der Fenster (Titelzeile, Schaltknöpfe, usw.). X11 ist da anders. Bei X11 werden die Fensterrahmen (auch Dekoration genannt) von einem separaten Programm erstellt, der Fensterverwaltung. In vielerlei Hinsicht ist die Fensterverwaltung auch nur ein weiterer Klient. Sie wird genau so gestartet und sendet über die gleichen Kanäle Mitteilungen an den X11-Server.
Man kann aus einer großen Anzahl von Fensterverwaltungen auswählen. xwinman.org ist eine sehr umfassende Liste. Bei den beliebtesten kann man das Aussehen über themes verändern. Bei vielen Fensterverwaltungen gibt es noch zusätzlich Funktionen, wie PopUp-Menus im Wurzelfenster, ein Dock oder Startknöpfe.
Viele Fensterverwaltungen gibt es als Pakete in Fink. Die folgende Seite zeigt die aktuelle Liste.
Alle sind Schreibtischumgebungen und es gibt noch viele andere. Sie stellen den Programmen Frameworks zur Verfügung, so dass ihr Aussehen, ihre Bedienung und Verhalten visuell konsistent ist. Ein Beispiel:
Grafiksystem: X11
Fensterverwaltung: sawfish
Schreibtischumgebung: Gnome
Die Grenze zwischen Grafiksystem, Fensterverwaltung und Schreibtisch sind fließend, weil die gleichen oder zumindest ähnliche Funktionen in dem einem oder anderen oder sogar in mehreren realisiert sein kann. Deshalb kann es durchaus sein, dass eine Fensterverwaltung nicht zusammen mit einer bestimmten Schreibtischumgebung benutzt werden kann.
Viele Programme sind für eine bestimmte Schreitischumgebung geschrieben. Meistens reicht es deshalb aus, die Bibliotheken für die Schreibtischumgebung zu installieren. Das Programm funktioniert dann mit keinen oder nur geringen Einschränkungen. Ein Beispiel ist die zunehmende Auswahl an GNOME-Programmen, die auch ohne die Schreibtischumgebung GNOME verwendet werden können. Unglücklicherweise ist man bei den KDE-Programmen noch nicht ganz so weit.
[Entschuldigen bitte den epischen Tonfall.]
Am Anfang war die Leere. Darwin war noch in seinen Kindertagen, Mac OS X noch sehr in Entwicklung und es gab keine Implementierung von X11.
Dann trat John Carmack auf und portierte XFree86 auf Mac OS X Server, zu der Zeit das einzige Betriebsystem der Darwin-Familie. Später wurde der Port von Dave Zarzycki auf XFree86 4.0 und Darwin 1.0 aktualisiert. Die Patches wurden in das CVS-Repository von Darwin übernommen und wo sie in eine Art Dornröschenschlaf fielen.
Eines schönen Tages kam ein Prinz namens Torrey T. Lyons, küsste die Darwin-Patches und erweckte sie so aus ihrem Dornröschenschlaf. Schließlich gab er ihnen im offiziellen XFree86 CVS-Repository eine neue Heimat. Das geschah zur Zeit von Mac OS X Public Beta und Darwin 1.2. XFree86 4.0.2 funktionierte einwandfrei auf Darwin, aber auf Mac OS X mussten sich die Nutzer aus Aqua ausloggen und es von der Konsole aus starten. Deshalb versammelte Torrey das XonX-Team um sich und begann, XFree86 auf Mac OS X zu portieren.
Zur selben Zeit begann Tenon, mit XFree86 4.0 als Ausgangsbasis ihre Xtools zu erstellen.
Bald gelang es dem XonX-Team, dass XFree86 im Vollbildmodus parallel zu Quartz läuft und veröffentlichten Testversionen für risikofreudige Nutzer. Die Testversionen wurde XFree86-Aqua genannt oder kurz XAqua. Mit Torrey in der Führung wurden Änderungen direkt in das CVS-Repository von XFree86 übernommen, was zur Version 4.1.0 führte.
Am Anfang wurde die Schnittstelle zu Quartz mit einem kleinen Programm namens Xmaster.app realisiert. Es war zunächst in Carbon geschrieben, später dann in Cocoa. Dieser Code wurde dann in den tatsächlichen X-Server integriert und XDarin.app war geboren. Ab diesem Zeitpunkt wurden auch "shared" Bilbiotheken unterstützt und Tenon konnte überzeugt werden, die gleichen Patches statt eigener zu verwenden, um binäre Kompatibilität zu erreichen. Sogar im Hinblick auf einen "rootless" Modus wurden unter Verwendung der Carbon API große Fortschritte erreicht, aber war es zu spät für XFree86 4.1.0. Aber der "rootless" Patch war da und kursierte im Internet. Als XFree86 4.1.0 heraus kam und nur den Vollbild Modus hatte, wurde die Arbeit am "rootless" Modus fortgesetzt, aber jetzt unter Verwendung der Cocoa API. Ein experimenteller "rootless" Modus fand so seinen Weg in das CVS-Repository von XFree86.
Inzwischen wurden von Apple Mac OS X 10.0 und Darwin 1.3 veröffentlicht. Einige Wochen später folgte Tenon mit Xtools 1.0.
Die Entwicklung schritt fort und der "rootless" Modus wurde in XFree86 integriert, so dass bei der Veröffentlichung von XFree86 4.2.0 im Januar 2002, die Darwin/Mac OS X Version vollständig in die offizielle Distribution von XFree86 integriert war.
Am 7. Januar 2003 gab Apple eine Beta-Version ihrer eigenen X11-Implementation für OS 10.2 heraus. Sie basierte auf XFree86-4.2 und hatte Quartz-Rendering und beschleunigtes OpenGL. Am 10. Februar 2003 wurde eine neue Version mit zusätzlichen Features und Bugfixes heraus gegeben. Die dritte Version, also Beta 3, folgte am 17. März 2003 mit weiteren Features und Bugfixes.
Am 24. Oktober 2003 gab Apple Panther (Mac OS X 10.3) heraus, das als erste Version Apples eigene X11-Distribution enthielt, die auf XFree86-4.3 basierte.
Am 29. April 2005 gab Apple Tiger (Mac OS X 10.4) heraus, das eine X11-Distribution enthielt, die auf XFree86-4.4 basierte.
Am 26. Oktober 2007 gab Apple Leopard (Mac OS X 10.5) heraus, das eine X11-Distribution enthielt, die auf X.org-7.2 basierte.
Am 28. August 2009 gab Apple Snow Leopard (Mac OS X 10.6) heraus, das eine X11-Distribution enthielt, die auf X.org-7.2 basierte.
Am 20. Juli 2011 gab Apple Lion (Mac OS X 10.7) heraus, das eine X11-Distribution enthielt, die auf XQuartz-2.6.4 basierte.
Am 25. Juli 2012 gab Apple Mountain Lion (Mac OS X 10.8) heraus. Für diese Version ist XQuartz-2.7.2 oder später die richtige X11-Distribution.
Alle Version von OS X, die derzeit von Fink unterstützt werden, benutzen eine X11-Distribution von Apple. Die unterstützten Konfigurationen sind:
10.5: Fink unterstützt das eingebaute X11 und XQuartz-2.6.3 oder früher.
Beachte: Apples X11 auf 10.6 hat Bibliotheken mit älteren Versionen als bei XQuartz-2.4. Eine Installation von XQuartz macht deshalb eine Aktualisierung von 10.5 auf 10.6 kompliziert.
10.6: Fink unterstützt nur das eingebaute X11. Man muss davon ausgehen, dass die Fink-Pakete nur mit dem eingebauten X11 erstellt werden können. Deshalb muss man bei der Installation von XQuartz dafür sorgen, dass das eingebaute X11 installiert bleibt.
10.7: Fink unterstützt nur das eingebaute X11. Man muss davon ausgehen, dass die Fink-Pakete nur mit dem eingebauten X11 erstellt werden können. Deshalb muss man bei der Installation von XQuartz dafür sorgen, dass das eingebaute X11 installiert bleibt.
10.8: Fink unterstützt nur XQuartz-2.7.2 und neuer.
Will man Pakete mit dem eingebauten X11 auf 10.5-10.7 und Xcode <= 4.2.1 erstellen, muss man sicher stellen, dass auch das X11 SDK installiert ist (auch wenn das normalerweise der Fall ist.). XQuartz-Nutzer auf 10.5 sollten es aber auf keinen Fall installieren, weil XQuartz bereits alles enthält. Auf 10.7 enthalten die Command Line Tools für Xcode >= 4.3 das X11 SDK. Auf 10.8 muss man nur XQuartz installieren.
Alle X11 Pakete bieten Vollbild- und "rootless" Modus und unterstützen OpenGL.
Weitere Informationen zur Benutzung von Apples X11 stehen in diesem Artikel der Apple Developer Connection.
Fink verfolgt the Status von X11 über einige virtuelle Pakete. Die wichtigsten sind:
Notiz: Die Existenz separater system-xfree86*- und x11*-Familien ist ein Erbe aus Zeiten vor 10.5, als Fink noch seine eigenen X11-Pakete enthielt, die ebenfalls die x11-Familie zur Verfügung stellten.
Fehlt eines dieser Pakete, dann fehlen Dateien aus der X11 Installation, die sie (nach-)installieren müssen. Fehlen zum Beispiel x11-dev oder system-xfree86-dev, wurde meistens vergessen, das X11 SDK zu installieren.
X11 kann unter Mac OS X auf drei Arten gestartet werden.
Die erste Art ist die X11-Applikation zu starten, d. h. ein Doppelklick auf das Programm im Finder. Unter 10.5-10.7 ist das typischerweise /Applications/Utilities/X11(.app), oder /Applications/Utilities/XQuartz(.app), wenn man Xquartz benutzt (also unter 10.8).
Die zweite Art ist die Eingabe des Kommandos startx in einem Terminalfenster.
Die dritte Art ist, einfach ein Programm in einem Terminalfenster zu starten, das X11 benötigt. Ab 10.5 startet dies automatisch einen X11-Server.
Für derzeitige Versionen von X11 ist die bevorzugte Methode seinen Start zu modifizieren, ein Verzeichnis .xinitrc.d im $HOME Verzeichnis anzulegen und mit ausführbaren Skripten zu füllen, die die Programme starten, die man beim Start haben möchte, einschließlich Fensterverwaltungen.
Wichtig: Hinter Programmen, die keine Fensterverwaltungen sind, muss ein '&'stehen. Andernfalls blockieren sie die Ausführung anderer Programme, auch Fensterverwaltungen. Fensterverwaltungen dürfen kein '&' hinter ihrem Namen haben, ansonsten bleiben sie nicht laufen, außer es gibt eine Sessionverwaltung, die nach ihr startet. Das Programm xinit interpretiert diese Situation so, dass nach dem Ende der Session auch der X-Server beendet werden soll.
Beispiel: Soll die Fensterverwaltung WindowMaker mit dem Start des X11-Server starten, geben sie folgende Komanndos ein:
mkdir -p $HOME/.xinitrc.d nano $HOME/.xinitrc.d/94-wmaker.sh
Sie können auch ihren Lieblingseditor statt nano verwenden. Tragen sie folgenden Inhalt in 94-wmaker.sh ein:
. /opt/sw/bin/init.sh quartz-wm --only-proxy & exec wmaker
Speichern sie die Datei und führen sie folgendes Kommando aus:
chmod a+x 94-wmaker.sh
Damit wird das Skript ausführbar. (quartz-wm --only-proxy wird in einem späteren Abschnitt diskutiert).
Beispiel: Soll das Programm xlogo mit dem Start des X11-Server starten, geben sie folgende Komanndos ein:
mkdir -p $HOME/.xinitrc.d nano $HOME/.xinitrc.d/74-xlogo.sh
(wie oben: wenn sie wollen, nehmen sie ihren Lieblingseditor). Tragen sie folgenden Inhalt in 74-xlogo.sh ein:
. /opt/sw/bin/init.sh xlogo &
Speichern sie die Datei und führen sie folgendes Kommando aus:
chmod a+x 74-xlogo.sh
Damit wird das Skript ausführbar.
Erstellen sie die beiden Skripts, resultiert daraus, dass beim Start von X11 das Programm xlogo ausgeführt wird und dann die Fensterverwaltungwmaker.
Beispiel: Vollständige GNOME-Session. Erzeugen sie die ausführbare Datei 94-gnome-session.sh mit folgendem Inhalt:
. /opt/sw/bin/init.sh quartz-wm --only-proxy & metacity & exec gnome-session
Beispiel: "rootless" GNOME-Session. Erzeugen sie die ausführbare Datei 94-gnome-panel.sh mit folgendem Inhalt:
. /opt/sw/bin/init.sh quartz-wm --only-proxy & metacity & exec gnome-panel
Beispiel: KDE3. Erzeugen sie die ausführbare Datei 94-startkde.sh mit folgendem Inhalt:
. /opt/sw/bin/init.sh exec startkde
(startkde startet automatisch eine Fensterverwaltung und nutzt quartz-wm --only-proxy)
Beispiel: KDE4. Erzeugen sie die ausführbare Datei 94-startkde.sh mit folgendem Inhalt:
. /opt/sw/bin/init.sh exec /opt/sw/opt/kde4/x11/bin/startkde
Beachte:
Notiz: Es ist besser, mit Skripten im Verzeichnis $HOME/.xinitrc.d zu arbeiten.
Existiert eine Datei mit dem Namen .xinitrc im Heimatverzeichnis, wird sie benutzt, um X-Klienten zu starten, eine Fensterverwaltung, einige xterm Terminals oder eine Schreibtischumgebung wie GNOME. Die Datei .xinitrc ist ein /bin/sh-Skript mit den Kommandos dafür. Das übliche #!/bin/sh in der ersten Zeile wird nicht benötigt; die Datei muss auch nicht ausführbar sein. xinit wird die Datei immer mit der Shell /bin/sh ausführen.
Gibt es keine Datei .xinitrc im Heimat-Verzeichnis und auch kein Verzeichnis $HOME/.xinitrc.d, dann benutzt X11 die Voreinstellungen in der Datei /usr/X11/lib/X11/xinit/xinitrc. Die Voreinstellungen kann man auch gut als Ausgangspunkt für eine eigene Datei .xinitrc verwenden:
cp /usr/X11/lib/X11/xinit/xinitrc ~/.xinitrc
Damit auch Fink-Programme in .xinitrc funktionieren, sollte gleich am Anfang der Datei die Zeile . /opt/sw/bin/init.sh stehen, damit die Umgebung korrekt aufgesetzt wird.
Man kann so ziemlich alles in die Datei .xinitrc schreiben, aber einiges sollte man dabei doch beachten. Erstens: Die Shell, die die Datei abarbeitet, wartet bis bei jedem Programm bis es beendet wird, bevor das nächste Programm gestartet wird. Sollen mehrere Programme parallel laufen, muss man der Shell mitteilen, sie in den Hintergrund zu verschieben, indem man am Ende der Zeile ein & anhängt.
Zweitens: xinit Wartet bis das Skript in .xinitrc beendet ist und inerpretiert diese Situation, dass die Session beendet ist und der X-Server jetzt auch beendet werden soll. Dies bedeutet, dass das letzte Kommando in .xinitrc nicht im Hintergrund ablaufen sollte und ein langlebiges Programm sein sollte. Üblicherweise ist es die Fensterverwaltung oder die Schreibtischumgebung. Tatsächlich gehen die meisten Fensterverwaltungen und Schreibtischumgebungen davon aus, dass xinit auf ihr Ende wartet und dies für den "Log Out" Eintrag in ihren Menus nutzen. (Notiz: Man kann etwas Speicher und CPU-Last zu sparen, wenn man exec an den Anfang der letzten Zeile schreibt, so wie in den folgenden Beispielen.)
Beispiel: Schalte die X11-Klingel aus, starte einige Klienten und zum Schluss die Fensterverwaltung "Enlightenment":
. /opt/sw/bin/init.sh xset b off xclock -geometry -0+0 & xterm & xterm & exec enlightenment
Beispiel: GNOME starten:
. /opt/sw/bin/init.sh quartz-wm --only-proxy & metacity & exec gnome-session
Zum Schluss: KDE3 starten:
. /opt/sw/bin/init.sh exec startkde
Manche Fink-Pakete müssen beim Start von X11 einige Aktionen ausführen. Dafür gibt es ein Paket namens xinitrc (zugegebenermaßen etwas verwirrend). Eine Nebenwirkung bei der Installation dieses Pakets, das in der Abhängigkeitskette von GNOME und KDE ist, dass die voreingestellte Ausführung der Skripte in $HOME/.xinitrc.d. Es gibt einige Methoden, mit denen man den Start von X11 modifizieren kann und Fink-Paketen erlauben kann, ihre Start-Aktionen auszuführen:
Das Paket xinitrc enthält Einsprungspunkte für Administratoren. Erzeugen sie die Datei /opt/sw/etc/xinitrc-last-hook als Administrator mit folgendem Inhalt:
#!/bin/sh . /usr/X11/lib/X11/xinit/xinitrc.d/98-user.sh
Damit hat man das urspüngliche Verhalten, dass im Verzeichnis $HOME/.xinitrc.d nach ausführbaren Skripten gesucht wird.
Erzeugen sie die Datei $HOME/.xinitrc wie im Abschnitt .xinitrc beschrieben. Finks Paket xinitrc überschreibt die Voreinstellung des Systems mit seiner eigenen Version und damit nutzt man die Version von Fink.
Der richtige Platz für zusätzliche Programme, die sofort ausgeführt werden sollen, ist vor folgender Zeile:
# start the window manager
VNC ist eine netzwerktransparentes System für grafische Darstellungen mit Ähnlichkeiten zu X11. Allerdings arbeitet es auf einem niedrigeren Ebene, was die Implementierung vereinfacht. Mit dem Xvnc-Server und einem Mac OS X Display-Klienten kann man X11-Programme mit Mac OS X ausführen. Fink hat ein X11-basiertes Paket für einige Platformen. Lesen sie die Einträge auf folgender Seite durch.
WeirdX ist ein in Java geschriebener X11-Server. Es unterstützt auch den "rootless" Modus. Quellcode und eine java jar-Datei gibt es auf der Webseite.
Zu allererst: Nur keine Panik! Bei X11 kann einiges schief gehen und vieles davon führt zu einem Abbruch beim Start. Es ist also nicht wirklich ungewöhnlich. In diesem Abschnitt werden möglichst alle Fälle beschrieben, mit denen man rechnen muss. Als erstes muss man sich um folgende zwei Informationen kümmern:
Die version des Display-Server. Die Version des Display-Server findet man im Finder, wenn man einmal auf das Symbol von X11 oder XQuartz klickt und dann "Informationen" aus dem Menu "Ablage" auswählt. Dasselbe erreicht man auch mit Command-I.
Fehlermeldungen. Fehlermeldungen sind von enormer Bedeutung, um das jeweilige Problem einzugrenzen. Wie die Fehlermeldungen ausgegeben werden, hängt davon ab, wie sie X11 gestartet haben. Haben sie startx in einem Terminalfenster eingegeben, werden Fehlermeldungen direkt in gleichen Fenster ausgegeben. Oft muss man zum Lesen nach oben blättern. Haben sie X11 durch einen Doppleklick von X11 or XQuartz gestartet, landen die Fehlermeldungen im System-Log, den man mit dem Programm "Konsole" aus dem Ordner "Dienstprogramme" lesen kann. Man muss aufpassen, dass man die richtigen Meldungen liest, also die letzten.
Im folgenden einige Fehlermeldungen. In vielen Fällen ist die deutsche Übersetzung nicht bekannt, weshalb normalerweise das englische Original beschrieben wird.
_XSERVTransmkdir: Owner of /tmp/.X11-unix should be set to root
_IceTransmkdir: Owner of /tmp/.ICE-unix should be set to root
Klassifizierung: Harmlos. X11 erzeugt versteckte Verzeichniss in /tmp, um "Socket-Dateien" für lokale Verbindungen zu speichern. Aus Sicherheitsgründen gibt X11 diesen Verzeichnissen den Eigentümer "root". Sie haben aber sowieso Schreibzugriff für alle, so dass X11 ohne Probleme läuft. (Notiz: Es ist recht schwierig, diesen Verzeichnissen den Eigentümer "root" zu geben, weil Mac OS X bei einem Neustart /tmp löscht und X11 nicht mit "root"-Rechten läuft und auch nicht muss.)
cat: /Users/chrisp/.Xauthority: No such file or directory
Klassifizierung: Meistens harmlos. Dieser Fehler hat anscheinend keinerlei Auswirkungen. Sie können den Fehler durch Eingabe des Kommandos touch .Xauthority im Heimatverzeichnis los werden.
Gdk-WARNING **: locale not supported by C library
Klassifizierung: Harmlos. Es bedeutet genau das, was es sagt und verhindert nicht das normale Funktionieren eines Programms. Weitere Information dazu finden sie weiter unten im Agbschnitt Locale.
Warning: no access to tty (Inappropriate ioctl for device). Thus no job control in this shell.
Klassifizierung: Meistens harmlos. X11 startet im Hintergrund eine interaktive Shell, um die Startdatei des Klienten (.xinitrc) auszuführen. Dadurch braucht man keine Kommandos um den Pfad "PATH" zu setzen. Einige Shells beschweren sich, dass es keine Verbindung zu einem echten Terminal gibt, was aber ignoriert werden kann, weil diese Shell keine Job-Kontrolle durch Eingabe oder ähnliches benötigt.
The XKEYBOARD keymap compiler (xkbcomp) reports: > Error: Can't find file "unknown" for geometry include > Exiting > Abandoning geometry file "(null)" Errors from xkbcomp are not fatal to the X server
Klassifizierung: Meistens harmlos. Wie die Nachricht sagt, ist der Fehler nicht fatal. So weit bekannt, nutzt X11 auf Mac OS X keine XKB-Erweiterungen. Einige Klienten-Programme können aber dennoch versuchen, diese Erweiterungen zu verwenden ...
startx: Command not found.
Klassifizierung: Fatal. Dieser Fehler kann auftreten, wenn Initialisierungsdateien nicht so aufgesetzt sind, dass das Verzeichnis mit den X11-Programmen, also /usr/X11/bin nicht in der Pfad-Variablen PATH eingetragen ist. Die Einstellung in Fink is normalerweise so, dass dies automatisch der Fall ist. Deshalb ist dieser Fehler ein Hinweis darauf, dass die Fink-Umgebung noch nicht richtig aufgesetzt ist. Führt man das Kommando
/opt/sw/bin/pathsetup.sh
in einem Terminalfenster aus und startet ein neues Fenster, ist der Fehler meistens behoben.
_XSERVTransSocketUNIXCreateListener: ...SocketCreateListener() failed _XSERVTransMakeAllCOTSServerListeners: server already running
Fatal server error: Cannot establish any listening sockets - Make sure an X server isn't already running
Klassifizierung: Fatal. Dieser Fehler tritt auf, wenn zufällig mehrere Instanzen von X11 zur selben Zeit laufen oder wenn X11 durch einen Absturz nicht sauber beendet wurde. Es kann auch an einem Problem mit Zugriffsrechten auf Sockets für lokale Verbindungen liegen. Sie können versuchen, das Problem mit dem Kommando rm -rf /tmp/.X11-unix zu beheben. Ansonsten bleibt noch ein Neustart von Mac OS X, bei dem /tmp automatisch aufgeräumt und der Netzwerk-Stack zurückgesetzt wird.
Xlib: connection to ":0.0" refused by server Xlib: Client is not authorized to connect to Server
Klassifizierung: Fatal. Das Klienten-Programm bekommt keine Verbindung mit dem Display-Server (X11 oder XQuartz), weil die Daten für die Authentifizierung nicht stimmen. Dies wird durch einige Installationen von VNC verursacht, indem sie X11-basierte Programme mittels sudo laufen lassen oder auch durch sonstige schräge Einstellungen. Normalerweise lässt sich dieser Fehler dadurch beheben, im Homeverzeichnis die Datei .Xauthority zu löschen (in ihr werden die Daten für die Authentifizierung abgespeichert) und eine neue, leere Datei zu erzeugen:
cd rm .Xauthority touch .Xauthority
Kein offensichtlicher Fehler:
Klassifizierung: Fatal. Der wohl häufigste Fehler beim Start von X11 ist eine fehlerhafte Start-Datei. Typischerweise ist eine Fensterverwaltung aus $HOME/.xinitrc oder $HOME/.xinitrc.d nicht installiert, nicht im PATH, läuft im Hintergrund statt im Vordergrund, weil ein '&' am Ende der Zeile steht. Wie auch immer läuft xinit bis zum Ende der Datei und interpretiert dies als Ende der Nutzer-Session und beendet X11. Wird eine Programm nicht gefunden, gibt es dazu eine Fehlermeldung im Terminalfenster oder dem Konsolen-Log. Hat aber die letzte Datei ein '&', gibt es keine Fehlermeldung, sondern X11 hört einfach auf. In den Abschnitten .xinitrc.d und Die Datei .xinitrc stehen weitere Details dazu.
Wollen sie das verhindern, vergessen sie nicht in der Start-Datei die Pfad-Variable PATH mit folgendem Kommando zu setzen:
. /opt/sw/bin/init.sh
Außerdem sollte die Start-Datei mit einem langlebigen Programm enden, das nicht im Hintergrund läuft, z. B. einer Fenster- oder Sessionverwaltung ohne '&'. Zur Sicherheit kann man auch ein exec xterm als Rückfalloption hinzu fügen, falls die Fensterverwaltung nicht gefunden wird, weil sie sie z. B. selbst entfernt haben.
Diese Warnungen sind recht häufig, aber harmlos. Sie bedeuten genau das, was sie sagen - Internationalisierung wird nicht durch Standard C-Bibliotheken unterstützt und das Programm wird die normalen englischen Text, Datumsformate und so weiter benutzen. Es gibt mehrere Möglichkeiten damit umzugehen:
Ignorieren sie einfach die Meldung.
Verhindern sie die Meldungen in dem sie die Environment-Variable LANG löschen. Beachten sie, dass dies auch die Internationalisierung in Programmen ausschaltet, die sie über gettext/libintl unterstützen. Ein Beispiel für .xinitrc:
unset LANG
Ein Beispiel für .cshrc:
unsetenv LANG
Bitten sie Apple, dass sie eine zukünftige Version von Mac OS X um eine ordentliche Unterstützung von locale ergänzen.
Programme, die andere Fink-Programme für Teilaufgaben aufrufen, brauchen eine Ergänzung, wenn man sie aus dem Menu "Programme" starten möchte. Anstatt den ganzen Pfad zu der Datei anzugeben, also
/opt/sw/bin/emacs
sollte man z. B. bei bash besser folgendes eintragen:
. /opt/sw/bin/init.sh ; emacs
und bei tcsh:
source /opt/sw/bin/init.csh ; emacs
Damit ist sicher gestellt, dass das Programm die korrekte PATH-Information hat. Diese Syntax kann man für jedes Programm verwenden, das mit Fink installiert wurde.
Beachte: Anscheinend kann man doch nicht alle Programme so starten.
Der Start von X11-Programmen aus einem Fenster der Terminal(.app) (oder jedem anderen nicht-X11-Terminal) erfolgt bei den aktuellen Version von X11 ab 10.5 direkt. Geben sie den Namen des Programms genau so ein, wie für ein Kommandozeilenprogramm und OS X wird fall nötig X11 starten und dann ihre Programm.
Wichtig: Vor OS X 10.5 musste man die Environment-Variable DISPLAY in der Terminalsession setzen, damit sie mit X11 Verbindung aufnimmt. Tun sie das auf keinen Fall auf OS X 10.5 und neuer, denn OS X setzt dies automatisch auf den richtigen Wert.
Wollen sie Aqua-Programme aus xterm oder jeder anderen Shell starten, geben sie das Kommando open ein. Einige Beispiele:
open /Applications/TextEdit.app open SomeDocument.rtf open -a /Applications/TextEdit.app index.html
Das zweite Beispiel öffnet das Dokument mit dem Programm, das mit ihm assoziiert ist; im dritten Beispiel wird das Programm explizit angegeben.
Das Kommando launch aus dem Fink-Paket launch funktioniert genauso, bietet aber noch einige zusätzliche Funktionen.
Im allgemeinen funktionieren Kopieren und Einfügen zwischen der Aqua- und der X11- Umgebung, wenn auch nicht zu 100%. Emacs ist dafür bekannt, dass es hinsichtlich der aktuellen Auswahl "wählerisch" ist. Aus der Classic-Umgebung funktionieren Kopieren und Einfügen nicht.
In jedem Fall muss man die jeweiligen Methoden der Umgebung nutzen, in der man gerade ist. Will man Text aus Aqua nach X11 transferieren, drücken sie Command-C in Aqua, bringen das Zielfenster ganz nach vorne und drücken den "mittleren" Maustaste, d. h. Option-Klick auf einer Maus mit nur einer Taste, für das Einfügen (Dazu muss "Emulate three button mouse" in den X11-Einstellungen eingeschaltet sein). Will man Text aus X11 nach Aqua transferieren, wählen sie den Text in X11 aus und drücken sie Command-C für das Kopieren und dann Command-V in Aqua für das Einfügen. Je nach Version von OS X und X11, funktioniert auch die Kopieren-Funktionen, um eine Auswahl zu kopieren.
Das X11-System hat tatsächlich mehrere Clipboards (Eigentlich in X11 "cut buffers" genannt) und einige Programme haben etwas seltsame Vorstellungen, welche man nehmen soll. Deshalb hat z. B. Einfügen in GNU Emacs oder XEmacs nicht funktioniert. Die Fensterverwaltung quartz-wm von Apple bügelt einige der Synchronisationsprobleme zwischen den Puffern aus. Wollen sie eine andere Fensterverwaltung verwenden, können sie die Vorteile von quartz-wm auf 10.5-10.7 immer noch ausnutzen, in dem sie die Option --only-proxy verwenden:
... quartz-wm --only proxy & exec <your window manager here>
Beachte: Diese Option wird von quartz-wm ab Xquartz-2.7.x nicht mehr unterstützt.
Das Programm autocutsel ist veraltet, steht aber auf 10.5 und 10.6 immer noch zur Verfügung, wenn sie quartz-wm --only proxy nicht verwenden wollen. Es synchronisiert automatisch zwischen den beiden Ausschneide-Puffern. Wenn sie es benutzen wollen, installieren sie das Fink-Paket autocutsel und ergänzen sie ihre Datei .xinitrc oder seine eigene in .xinitrc.d um diese Shellskript:
autocutsel &
Beachten sie, dass das Programm läuft, bevor die Fensterverwaltung gestartet wird und nicht beendet wird, also nicht einfach am Ende dazu schreiben. Dort wird es nie ausgeführt.
Wenn es Probleme mit Kopieren und Einfügen von Aqua nach X11 und anders herum gibt sollten sie es einfach noch einmal probieren. Manchmal erfolgt das Kopieren nicht sofort. Klappt das immer noch nicht, dann probieren sie es über ein drittes Programm, z. B. TextEdit oder Terminal auf der Seite von Aqua und nedit oder xterm auf der Seite von X11. Nach allgemeiner Erfahrung gibt es immer eine Lösung.
Copyright (c) 2001 Christoph Pfisterer, Copyright (c) 2001-2020 The Fink Project. You may distribute this document in print for private purposes, provided the document and this copyright notice remain complete and unmodified. Any commercial reproduction and any online publication requires the explicit consent of the author.
Generated from $Fink: x11.de.xml,v 1.2 2023/08/04 5:08:13 nieder Exp $