X Resourcen

X Resourcen

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 Applikationen.
Beinahe alles kann vom Anwender geändert bzw. angepaßt werden.

Übersicht

Jede X Applikation, die das X Toolkit verwendet, bringt globale Defaultwerte ihrer Resourcen mit, entweder fest einkodiert oder klassisch unter /usr/X11R6/lib/X11/app-defaults/

Diese globalen Applikationsresourcen 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 Applikation bietet und welche damit gegebenfalls modifiziert werden können.
Weitere Ansatzpunkte sind natürlich auch die jeweiligen Manpages der Applikationen und – falls von der Applikation unterstützt – das Programm editres, mit dem man die Resourcen einer Applikation 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:                 medium spring green

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.
Will man z.B. nur die Vordergrundfarbe des Scrollbalkens ändern, muß man die Resource in der Form "XTerm*Scrollbar*foreground" oder ähnlich definieren.

Auch den Standardcursor kann man ohne weiteres ändern. Eine Auswahl der verfügbaren Cursor findet man gewöhnlich in /usr/X11R6/include/X11/cursorfont.h

    ProgramName*pointerShape:         cursor_name
    ProgramName*Cursor:               cursor_name    

Konfigurationshierarchie

Resourcen werden Widgets in absteigender Reihenfolge wie folgt zugewiesen:

1. während der Erzeugung zugewiesene Resourcen (kodiert vom Programmierer)
2. Kommandozeilenargumente (Endnutzer)
3. hostspezifische Anwenderdefaults (Endnutzer)
4. serverspezifische Anwenderdefaults (Endnutzer)
5. applikationsspezifische Anwenderdefaults (Endnutzer)
6. systemweite applikationsspezifische Defaults (Programmierer/Admin)

2-6 werden dabei nur einmalig beim Applikationsstart wirksam.
3-6 führen dabei zu dauerhaften Einträgen in der X Resourcendatenbank.

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 weder übergehen noch überschreiben.

2. Kommandozeilenargumente (Endnutzer)

Das X Toolkit erlaubt es, bestimmte Standardresourcen über die Kommandozeile zu definieren. Diese Resourcen haben auf Endnutzerebene die höchste Priorität und überschreiben gegebenenfalls alle vorher gesetzen Endnutzerresourcen.

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
-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 (Endnutzer)

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 Applikation gestartet wird.
Man verwendet dies, wenn eine Applikation nicht für jeden Rechner die gleichen Resourcen verwenden soll.

4. serverspezifische Anwenderdefaults (Endnutzer)

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 Rootwindow.
Mit "xprop" kann man sich den Inhalt des RESOURCE_MANAGER property übrigens ansehen, wenn man es auf das Rootwindow (den Bildschirmhintergrund) 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ß das verwendete Datenfile zuerst vom C-Präprozessor ausgewertet wird, so daß man bedingte Resourcenspezifikationen verwenden kann:

#ifdef COLOR
  XTerm*background: wheat
#else
  XTerm*background: white
#endif

Nachteilig ist, daß die Resourcen von xrdb in das property des Rootwindow geladen werden, so daß der X Server mehr Speicher braucht und sich die Startzeit aller X Applikationen verlängert.
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 (Endnutzer)

Diese funktionieren auf der Applikationsebene und werden daher in Dateien abgelegt, deren Namen die Applikationsklasse 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.

1. Wenn die Umgebungsvariable $XUSERFILESEARCHPATH gesetzt ist, wird diese von Xt verwendet, 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 Substitution 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:

   <root>/%L/%N%C:\  (R5)
   <root>/%l/%N%C:\  (R5)
   
   <root>/%N%C:\     (R5)
   <root>/%L/%N:\
   <root>/%l/%N:\
   <root>/%N:\
   

   <root> ist entweder der Wert von $XAPPLRESDIR oder des Endnutzers Homeverzeichnis falls $XAPPLRESDIR nicht definiert ist. Falls $XUSERFILESEARCHPATH wie gesagt abweichend vom Default definiert wird, ignoriert Xt $XAPPLRESDIR völlig.

2. Falls die Umgebungsvariable $XUSERFILESEARCHPATH nicht gesetzt ist, sucht Xt im duch die Umgebungsvariable $XAPPLRESDIR festgelegten Verzeichnis, wobei eine Anzahl vordefinierter Substitutionsregeln benutzt werden.

   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 Applikationen zu wahren.

3. Falls 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 (Pfad + Name + Extension) Dateinamen des Resourcenfiles 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())

   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 Applikation 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 wiederum ein applikationsspezifischer Wert, der auf beliebigen vorherigen Resourcenebenen gesetzt werden kann. Der Resourcenname ist "xnlLanguage" und gehört zur Klasse "XnlLanguage". Ist diese Resource nicht definiert, versucht Xt einen Wert aus der Umgebungsvariable $LANG (der shell) 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 Endnutzerresourcen zuzuweisen.

Diese Ebene ä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 Endnutzer 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 Funktionsfähigkeit einer Applikation sicherzustellen.
Sie werden nur dann verwendet, falls entsprechende Resourcen noch nicht in einer der vorherigen Ebenen definiert wurden.

Systemweite applikationsspezifische (fallback) Defaults finden sich i.d.R. unter /usr/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 dort keine passenden Resourcen, werden – so sie vom Programmierer definiert wurden – die einkompilierten Fallbacks verwendet.