XConfig - XResourcen

XResourcen

Text zur Verfügung gestellt von Marcus Jodorf.

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: value

angeben.
Um die Standardtextfarbe des xterm zu ändern, könnte man beispielsweise

XTerm*foreground: mediumspringgreen

definieren.
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_name

Eine 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)

2-6 werden dabei nur einmalig beim Anwendungsstart wirksam.
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.

Folgende Resourcenspezifikationen über Kommandozeile sind möglich:
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

3. hostspezifische Anwenderdefaults (Benutzer):

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.

4. serverspezifische Anwenderdefaults (Benutzer):

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
#endif

Nachteilig 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.

5. applikationsspezifische Anwenderdefaults (Benutzer):

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.
Xt versucht allerdings zuvor einen fest einkompilierten 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.)
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 auch XtResolvePathname(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 Klasse XApp 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 mit xrdb 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 Resource customization also zu /users/u2/XApp-color expandieren.

Anmerkung: Die Resource customization 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 Klasse XnlLanguage. Ist diese Resource nicht definiert, versucht Xt einen Wert aus der Umgebungsvariable (der Shell) $LANG zu extrahieren. (Siehe auch "locales" in der X Dokumentation.)

6. systemweite applikationsspezifische Defaults (Programmierer / Admin):

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/%N

auf 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.

[XConfig - Hauptseite]

Fragen, Kritik und Fehlermeldungen an: Alexander+XConfig@Leidinger.net