davec@gssc.UUCP (09/16/88)
I've got several questions and comments regarding the resource manager
on X11 Release 2:
1) When a client is brought up, defaults are set in the following order:
1) /usr/lib/X11/app-defaults/class, if a toolkit client
2) server defaults via xrdb
3) if no server defaults, then
$HOME/.Xdefaults
4) XENVIRONMENT
5) If XENVIRONMENT not set, then
$HOME/.Xdefaults-xxxx, where xxxx is the name
of the host where the client is running.
6) command line options
Why is there a separate .Xdefaults and .Xdefaults-xxxx file, and why
are they treated differently?
Why does the use of xrdb exclude the use of .Xdefaults?
2) .Xdefaults-xxxx quickly reaches the 14 char filename limit of sysV
and other OS's. This is not a friendly interface for users. It
would be more appropriate to collapse the name into something
shorter, such as .X11-xxxx, to fit well into more environments.
Are any plans in place to fix this in R3 or later releases?
3) I don't understand the purpose of .Xdefaults-xxxx files. Why would
I have a file called .Xdefaults-A on machine B? When the client is
started, the Toolkit and Xlib will look for $HOME/.Xdefaults-B. A
client started on machine A will look in A's file system, not B's.
The only possible reason for this I see is for use with distributed
filesystems, and even then it's a bit fuzzy.
4) /usr/lib/X11/app-defaults is a directory of files where the file name
is a classname. For xterm, the classname is XTerm. Each client has
it's own classname (as far as I can tell.) This is not documented
well. For instance, given the set of clients from MIT, what are the
given classnames? Is there a way for the user to specify classnames
at runtime?
Thanks for any answers to or comments on these issues.
Dave Cobbley
{decvax, ucbvax}!tektronix!sequent!gssc!davecswick@ATHENA.MIT.EDU (Ralph R. Swick) (09/16/88)
Date: Thu, 15 Sep 88 17:09:12 PDT
From: sequent!gssc!davec@decwrl.dec.com
Why is there a separate .Xdefaults and .Xdefaults-xxxx file, and why
are they treated differently?
Why does the use of xrdb exclude the use of .Xdefaults?
Here's the general philosophy: user preferences are most usefully
associated with _screens_, not with hosts (or filesystems, or...).
Clients connecting to a particular Display from anywhere in the
network should get the user's preferences. This can only happen
when they are stored in the server, thus the implementation of xrdb.
The fallback to .Xdefaults is only out of habit 'cause there have
been lots of users of X prior to the existence of xrdb and we didn't
want them to loose from day 1.
2) .Xdefaults-xxxx quickly reaches the 14 char filename limit of sysV
and other OS's.
Which is exactly why it's an environment variable.
Are any plans in place to fix this in R3 or later releases?
nope.
3) I don't understand the purpose of .Xdefaults-xxxx files.
The XENVIRONMENT option is a last-chance way for users to specify
customizations on a per-process basis. Providing a fall-back filename
may be a bug; it adds confusion, rather than clarity. The assumption
was that a frequent use of per-process customizations was to
modify the user's server defaults slightly (e.g. different backgrounds)
according to the host from which the client (e.g. xterm) was connecting.
4) /usr/lib/X11/app-defaults is a directory of files where the file name
is a classname. For xterm, the classname is XTerm. Each client has
it's own classname (as far as I can tell.)
Each client defines the class of which it is a member. The class may
include more than one application.
This is not documented
well.
guilty as charged.
For instance, given the set of clients from MIT, what are the
given classnames?
they all use the rule of "capitalize the first letter, or the first and
second letter if the first is 'x'".
Is there a way for the user to specify classnames
at runtime?
No. The class name is reserved to the application developer.diamant@hpfclp.SDE.HP.COM (John Diamant) (09/17/88)
> 4) /usr/lib/X11/app-defaults is a directory of files where the file name > is a classname. For xterm, the classname is XTerm. Each client has > it's own classname (as far as I can tell.) This is not documented > well. For instance, given the set of clients from MIT, what are the > given classnames? Is there a way for the user to specify classnames > at runtime? The classname needs to be documented by the client (in the man page would be appropriate). If they are not, look in the app-defaults directory to see if you can find the ones in use. For most applications, the classname is unique. This is by convention only, but it is very important if the app-defaults files are to be usable (since defaults are program specific). Unfortunately, the Inter-Client Communications Conventions Manual specifies that all window managers use the class "Wm" instead of a unique one. Not only is that inconsistent with common practice, but it makes an app-defaults file for window managers a very risky endevour. As far as whether you can specify a classname at runtime, the answer is no, unless the client goes to great pains to make it possible (XtInitialize parses command line arguments and .Xdefaults). Obviously, once XtInitialize has been called, it's too late to change the class value used in looking up the app-defaults file and resources in .Xdefaults. You can specify the name of an application (really, the instance) with -name on the command line, but app-defaults will not be looked up based on it. What is really needed is three different levels of resource lookup: instance win1 application name Emacs application class EDIT The toolkit has the first two of these, and calls them name and class. If the conventions were different, the name and class could correspond to what I called name and class above, but that doesn't work well with the existing mechanisms (name would have to be set on command line manually, class would make app-defaults useless, because different defaults are needed for different applications). If we had three levels instead of two, you could load Emacs specific entrires in an Emacs app-defaults file and EDITOR generic resources in an EDITOR app-defaults or via entries in .Xdefaults like: "EDIT*foreground: green" to make all your edit windows green regardless of which editor you used. John Diamant Software Development Environments Hewlett-Packard Co. ARPA Internet: diamant@hpfclp.sde.hp.com Fort Collins, CO UUCP: {hplabs,hpfcla}!hpfclp!diamant