XResourcen
Ein grundlegender Mechanismus von X ist die Verwendung sogenannter
Resourcen. Diese bestimmen unter anderem die verwendeten
Schriftarten, Fensterfarben, Cursorformen, Fenstergrößen,
Fensterpositionen und noch viele andere Dinge laufender
Anwendungen. Beinahe alles kann vom Anwender geändert
bzw. angepaßt werden. Dies gilt jedoch nur für Programme, die
das X Toolkit (libXt) benutzen, für z.B. GNOME/KDE Programme gilt dies nicht.
Um herauszufinden ob ein Programm das X Toolkit benutzt, kann man das Programm
ldd
(ldd /pfad/zu/programm
) verwenden. Erscheint
irgendwo in der Ausgabe von ldd
eine Zeile mit libXt,
dann verwendet dieses Programm das X Toolkit. Sollte ldd
sich mit der Ausgabe ldd: /pfad/zu/programm: not a dynamic
executable (oder ähnlich) beenden, dann kann keine Aussage darüber
gemacht werden, ob das X Toolkit verwendet wird, oder nicht.
Wie verändert man XResourcen:
Jede X Anwendung bringt globale Defaultwerte ihrer Resourcen
mit, entweder fest einkodiert oder klassisch unter
<XRoot>/lib/X11/app-defaults/
.
Diese globalen Anwendungsresourcen können dann z.B. entweder dort von priviligierten Usern (root) geändert oder von normalen Usern in ihrem Homeverzeichnis lokal für ihre jeweilige Umgebung überschrieben werden.
Die globalen Resourcenfiles sind ein guter Ansatzpunkt um
herauszufinden, welche spezifischen Resourcen eine Anwendung
bietet und welche damit gegebenfalls modifiziert werden können.
Weitere Ansatzpunkte sind natürlich auch die jeweiligen
man-Pages der Anwendungen und, falls von der Anwendung
unterstützt, das Programm editres
, mit dem man die
Resourcen einer Anwendung interaktiv erforschen und modifizieren kann.
Normale User können für Modifikationen in ihrem
Homeverzeichnis ein Resourcenfile (für gewöhnlich
.Xresources
oder auch .Xdefaults
genannt)
anlegen und in diesen Resourcen als einfachen Text in der Form
ProgramName*ResourceName: valueangeben.
Um die Standardtextfarbe des
xterm
zu ändern,
könnte man beispielsweise
XTerm*foreground: mediumspringgreendefinieren.
Resourcendefinitionen nutzen den
*
(Asterisk)
als Wildcard, so daß man sämtliche
foreground
-Resourcen des xterms
definiert,
wenn man die Form XTerm*foreground verwendet.
Damit sind z.B. dann auch die entsprechenden Resourcen von
SimpleMenu, VT100 und TEK Fenster und die Scrollbalken mit
eingeschlossen (siehe auch die man-Page zu xterm
).Will man z.B. nur die Vordergrundfarbe des Scrollbalkens ändern, muß man die Resource in der Form XTerm*Scrollbar*foreground oder ähnlich definieren.
Um lediglich eine bestimmte Resource zu verändern benutzt man den
.
(Punkt), um z.B. im mainMenu des
xterm
die Überschrift zu verändern, benutzt man
XTerm*mainMenu.Label. Würde man XTerm*mainMenu*Label
verwenden, so würde jeder Menüpunkt mit dem in der Resource angegebenen Text
überschrieben werden.
Auch den standard Mauszeiger kann man ohne weiteres ändern:
ProgramName*pointerShape: cursor_name ProgramName*Cursor: cursor_nameEine Auswahl der verfügbaren Mauszeiger findet man gewöhnlich in
<XRoot>/include/X11/cursorfont.h
.
Wo verändert man XResourcen:
Resourcen werden Widgets in absteigender Reihenfolge wie folgt zugewiesen:
- während der Erzeugung zugewiesene Resourcen (kodiert vom Programmierer)
- Kommandozeilenargumente (Benutzer)
- hostspezifische Anwenderdefaults (Benutzer)
- serverspezifische Anwenderdefaults (Benutzer)
- applikationsspezifische Anwenderdefaults (Benutzer)
- systemweite applikationsspezifische Defaults (Programmierer / Admin)
3-6 führen dabei zu dauerhaften Einträgen in der XResourcen Datenbank. 1. während der Erzeugung zugewiesene Resourcen (kodiert vom Programmierer):
Werden vom Programmierer im Programm festgelegt und wirksam, wenn ein Widget erzeugt wird. Man kann sie nicht übergehen oder überschreiben.
2. Kommandozeilenargumente (Benutzer):Das X Toolkit (libXt) erlaubt es, bestimmte Standardresourcen über die Kommandozeile zu definieren. Diese Resourcen haben auf Benutzerebene die höchste Priorität und überschreiben gegebenenfalls alle vorher gesetzen Benutzerresourcen.
Option | Resource | Wert |
---|---|---|
-background | *background | next arg |
-bd | *borderColor | next arg |
-bg | *background | next arg |
-borderwidth | .borderWidth | next arg |
-bordercolor | *borderColor | next arg |
-bw | .borderWidth | next arg |
-display | .display | next arg |
-fg | *foreground | next arg |
-fn | *font | next arg |
-font | *font | next arg |
-foreground | *foreground | next arg |
-geometry | .geometry | next arg |
-iconic | .iconic | next arg |
-name | .name | next arg |
-reverse | *reverseVideo | on |
-rv | *reverseVideo | on |
+rv | *reverseVideo | off |
-selectionTimeout | .selectionTimeout | next arg |
-synchronous | *synchronous | on |
+synchronous | *synchronous | off |
-title | .title | next arg |
-xnllanguage | .xnllanguage | next arg |
-xrm | other resources | next args |
Hostspezifische Anwenderdefaults finden sich in einer über
die $XENVIRONMENT
Variable zugewiesenen Datei oder,
wenn diese nicht gesetzt ist, in der Datei
${HOME}/.Xdefaults-<host>
, wobei
<host>
für den Namen des Rechners steht,
auf dem die Anwendung gestartet wird.
Man verwendet dies wenn eine Anwendung nicht für jeden Rechner
die gleichen Resourcen verwenden soll.
Man verwendet diese, um displayspezifische Resourcen zu definieren. Ein Beispiel wäre die Verwendung von Farb- und Monochrombildschirmen, wobei es dann sinnvoll ist jeweils an den Bildschirm angepaßte Resourcen zu verwenden.
Resourcen dieser Ebene sind jene, die beim Server- bzw. Sessionstart mittels
xrdb
(man xrdb
) zugewiesen werden.
Dies geschieht bei den meisten Installationen während des X Starts oder
während des Logins, z.B. in der systemweiten oder den persönlichen
(.)xinitrc
bzw. (.)xsession
, wobei dabei
mittels xrdb
i.d.R. ${HOME}/.Xresources
eingelesen wird. Die Resourcen befinden sich dann im
RESOURCE_MANAGER
property des root-Window. Properties sind
initialisierte Elemente / Inhalte der Widgetklassen. In diesem Fall
dient das Widget / die instantitierte Klasse des root-Window als Container
für die Resourcendatenbank (auch als Xrm bezeichnet).
Mit xprop
kann man sich den Inhalt des
RESOURCE_MANAGER property
übrigends ansehen, wenn
man es auf das root-Window anwendet.
Wird xrdb
nicht benutzt werden sie aus der Datei
${HOME}/.Xdefaults
gelesen.
Achtung: Wird xrdb
verwendet
(z.B. aus .xinitrc
heraus), so wird die Datei
${HOME}/.Xdefaults
nicht mehr ausgewertet!
Ein Vorteil der Benutzung von xrdb liegt darin, daß die verwendete Datendatei zuerst vom C-Präprozessor ausgewertet wird, so daß man bedingte Resourcenspezifikationen verwenden kann:
#ifdef COLOR XTerm*background: mediumspringgreen #else XTerm*background: white #endifNachteilig ist, daß die Resourcen von
xrdb
in das
Property des root-Window geladen werden, so daß der X Server
mehr Speicher braucht und sich die Startzeit aller X Anwendungen
verlängert. Das Problem ist dabei eniger die Größe in kB sondern,
daß es als reiner ASCII-Text in der Resourcendatenbank gehalten wird,
jeder startende X Client das via libXt vorgeworfen bekommt und dann
intern in der libXt ein Patternmatching abläuft um gegebenenfalls passende
Resourcen für den jeweiligen Client auszusieben und zu verwenden.(Für die jeweilige Applikation) unnötige Resourcen wirken sich also auf die Startzeit jeder einzelnen X Applikation aus, die sie jedesmal durchkauen muß. Das kann sich u.U. summieren.
Steckt da also z.B. 1kB an Text drin, muß jede einzelne Anwendung bei jedem Start 1kB Text parsen, selbst wenn nur vielleicht 50 Bytes für sie bestimmt sind.
So empfiehlt es sich so wenige Resourcen wie möglich mittels xrdb zu laden und lieber auf applikationsspezifische Anwenderdefaults auszuweichen, auch wenn das meist gegen die übliche Praxis ist.
Die durch xrdb
definierten Präprozessordirektiven
werden aufgelistet und erklärt in der xrdb
Dokumentation.
Diese funktionieren auf der Anwendungsebene und werden daher in
Dateien abgelegt, deren Namen die Anwendungsklasse wiederspiegeln.
Die X Intrinsics (libXt) sind recht flexibel, wenn es um den Zugriff auf
Resourcen geht, man kann das Verhalten mit den
Environmentvariablen $XFILESEARCHPATH
,
$XUSERFILESEARCHPATH
, und $XAPPLRESDIR
kontrollieren:
-
Wenn die Umgebungsvariable
$XUSERFILESEARCHPATH
gesetzt ist wird diese von Xt verwendet um die Resourcendatei zu finden.- Diese Umgebungsvariable besteht aus einer Liste
von Dateinamensubstituierungen, die durch "
:
" getrennt werden und die Regeln zur Bildung eines kompletten Dateinamens bilden (s.u.). - Die erste Substitution, die zum Erfolg führt, wird benutzt.
- Auch wenn keine Substution erfolgreich ist, werden die
nachfolgenden Schritte 2 und 3 nicht mehr
ausgeführt - diese werden nur ausgeführt,
wenn
$XUSERFILESEARCHPATH
nicht definiert ist.
XUSERFILESEARCHPATH
, der wie folgt aussieht:<Base>/%L/%N%C:\ (R5) <Base>/%l/%N%C:\ (R5) <Base>/%N%C:\ (R5) <Base>/%L/%N:\ <Base>/%l/%N:\ <Base>/%N:\
<Base> ist entweder der Wert von$XAPPLRESDIR
, oder wenn$XAPPLRESDIR
nicht definiert ist das Homeverzeichnis des Benutzers. Wenn$XUSERFILESEARCHPATH
abweichend vom Default definiert wird, ignoriert Xt$XAPPLRESDIR
völlig. (Die Erklärung der %* folgt unter Punkt 3.) - Diese Umgebungsvariable besteht aus einer Liste
von Dateinamensubstituierungen, die durch "
-
Wenn die Umgebungsvariable
$XUSERFILESEARCHPATH
nicht gesetzt ist, sucht Xt im duch die Umgebungsvariable$XAPPLRESDIR
festgelegten Verzeichnis, wobei eine Anzahl vordefinierter Substitutionsregeln benutzt wird.
Anmerkung:$XAPPLRESDIR
stammt aus X11R3 und älter. Seit R4 existiert der variablere*SEARCHPATH
Mechanismus, aber$XAPPLRESDIR
ist weiter gültig um die Kompatibilität zu älteren Anwendungen zu wahren. -
Wenn nach Schritt 2 noch keine Resourcendatei gefunden wurde, sucht Xt in
${HOME}
, wiederum unter Verwendung einer Anzahl vordefinierter Substitutionsregeln.
Die Substitutionsregeln werden aus Mustern aufgebaut die festlegen, wie Xt den kompletten Dateinamen (Pfad + Name + Erweiterung) der Resourcendatei aufbaut. Zu beachten ist, daß die Musterregeln auf Ebene der systemweiten applikationsspezifischen Defaults anders interpretiert werden, die Muster%T
und%S
(s.u.) wegfallen (siehe auchXtResolvePathname(3Xt)
)Muster Substitution %L <language> (z.B. de_DE.ISO8859-1) %l <language part of %L> (z.B. de) %N <app-class> - %C <custom-string> (nur >R5) Wenn z.B.
XUSERFILESEARCHPATH
/users/u2/%N%C
beinhaltet, und eine Anwendung der KlasseXApp
verwendet wird, expandiert das zu/users/u2/XApp<custom-string>
.<custom-string> ist dabei ein applikationsspezifischer Wert, der auf beliebigen vorherigen Resourcenebenen gesetzt werden kann. Eine übliche Definition wäre z.B. in
.Xresources
(wird mitxrdb
geladen und vom Präprozessor geparst):#ifdef COLOR *customization: -color #else *customization: -mono #endif
So wird, bei Benutzung eines Farbbildschirms, von Xt eine Resourcendatei<app-class>-color
geladen, an einem Monochromschirm<app-class>-mono
. Im obigen Beispiel würde es bei einer auf den Wert-color
gesetzten Resourcecustomization
also zu/users/u2/XApp-color
expandieren.
Anmerkung: Die Resourcecustomization
existiert seit R5.<language> ist wiedrum ein applikationsspezifischer Wert, der auf beliebigen vorherigen Resourcenebenen gesetzt werden kann. Der Resourcenname ist
xnlLanguage
und gehört zu KlasseXnlLanguage
. Ist diese Resource nicht definiert, versucht Xt einen Wert aus der Umgebungsvariable (der Shell)$LANG
zu extrahieren. (Siehe auch "locales" in der X Dokumentation.)
Dies ist keine endnutzerspezifische Ebene, aber es ist wichtig sie zu verstehen um eigene Benutzerresourcen zuzuweisen. Sie ähnelt der vorherigen, aber es gelten mehr Substitutionsregeln.
Muster | Substitution | |
---|---|---|
%L | <language> | (z.B. de_DE.ISO8859-1) |
%l | <language part of %L> | (z.B. de) |
%t | <territory part of %L> | (z.B. DE) |
%c | <code-set part of %L> | (z.B. ISO8859-1) |
%N | <app-class> | - |
%C | <custom-string> | (nur >R5) |
%S | <suffix> | - |
Diese Substitutionen werden im Kontext von
$XFILESEARCHPATH
verwendet. Ist dieses nicht definiert
wird ein vordefinierter Satz von Substitutionsregeln verwendet.
Auf dieser Ebene, sollte jede Resource mit *
(Asterisk)
verwendet werden, so daß ein Benutzer sie gemäß
den Vorrangregeln der X Resourcendatenbank (Xrm) einfach
überschreiben kann, indem er Resourcen mit dem Vorsatz von
<app-class>
oder <app-name>
verwendet.
Zur Ebene der systemweiten applikationsspezifischen Defaults gehören insbesondere auch die Fallback Resourcen die mindestens definiert sein müssen, um die Verwendungsfähigkeit einer Anwendung sicherzustellen. Sie werden nur dann verwendet, wenn entsprechende Resourcen noch nicht in einer der vorherigen Ebenen definiert wurden.
Systemweite applikationsspezifische (fallback) Defaults finden
sich i.d.R. unter <XRoot>/lib/X11/app-defaults
.
Man setzt $XFILESEARCHPATH
, wenn app-defaults Dateien
in verschiedenen Verzeichnishierarchien installiert wurden.
Beispielsweise führt
setenv XFILESEARCHPATH /usr/lib/X11/%T/%N:$OPENWINHOME/lib/%T/%Nauf einer Sun auf der sowohl X11Rx als auch Open Windows installiert wurden dazu, daß app-defauls unter /usr/lib/X11 und /usr/openwin/lib gefunden werden.
Finden sich auch unter XFILESEARCHPATH
keine passenden
Resourcen, werden, so sie vom Programmierer definiert wurden, die
einkompilierten Fallbacks verwendet.
Nun da wir wissen was XResourcen sind und wie sie verändert werden, wird es Zeit sich mal ein paar nützliche Beispiele anzusehen.
Fragen, Kritik und Fehlermeldungen an: Alexander+XConfig@Leidinger.net