[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Sawfish and Openbox: was fastest linux distro

Brian wrote:
> Vincent Lefevre wrote:
> > Brian wrote:
> > > I looked in the place that startx and the DMs look with a default
> > > install of X. Which is not to deny your valid point. However. a user
> > > would have to put in the extra effort to use .Xdefaults-<hostname> or,
> > > if they know it is possible, a .Xresources directory. I'm of the opinion
> > > that for most use cases mentioning .Xdefaults causes confusion at the
> > > very least.
> > 
> > There's no extra effort to use .Xdefaults-<hostname>: it's hardcoded
> > in libX11.

Actually all of .Xdefaults and .Xdefaults-$(hostname) and the
equivalent of .Xresources because it checks for "dpy->xdefaults == NULL"
are all hard coded in libx11.  And so all work in their own cases.

Previously written:
> Debian doesn't use a .Xdefaults file.
>    brian@desktop:~$ grep -r Xresources /etc/X11/
>    /etc/X11/Xsession:SYSRESOURCES=/etc/X11/Xresources
>    /etc/X11/Xsession:USRRESOURCES=$HOME/.Xresources

True.  But that is the default setting for 'startx'.  And for the
other xdb graphical login managers.  The .Xdefaults file is still used
if you avoid using 'startx'.  If you log in and simply use 'xinit'
without the startx wrapper around it and *don't* use xrdb yourself in
$HOME/.xinitrc then the $HOME/.Xdefaults is still consulted.  If you
have ever used xrdb to load resources into memory then .Xdefaults is
never consulted.  It is rather involved.

> Fair enough. Now, if only users were advised to use .Xdefaults-<hostname>
> or .Xresources. Instead the choice is always .Xdefaults or .Xresources.
> As I think we are agreed, one of these doesn't work. Ok, it can be made
> to work; for example I've seen linking .Xresources and .Xdefaults as a
> solution but have never quite grasped why .Xresource by itself is
> unsatisfactory.

Both work in different cases.  There are something like a half dozen
different locations that X resource data can be stored.  An X program
will look through each location in turn in priority order.  But if one
is shadowed by the other then one will appear not to work.

I posted on this topic before so instead of annoying the list with
a long posting I will simply point to the previous postings and
perhaps score them up in the search engines better.



This is what the code actually says now:


     * See lib/Xt/Initialize.c
     * First, get the defaults from the server; if none, then load from
     * ~/.Xdefaults.  Next, if there is an XENVIRONMENT environment variable,
     * then load that file.

    if (dpy->xdefaults == NULL) {
	const char *slashDotXdefaults = "/.Xdefaults";

	(void) GetHomeDir (fname, PATH_MAX - strlen (slashDotXdefaults) - 1);
	(void) strcat (fname, slashDotXdefaults);
	xdb = XrmGetFileDatabase (fname);
    } else {
	xdb = XrmGetStringDatabase(dpy->xdefaults);

    if (!(xenv = getenv ("XENVIRONMENT"))) {
	const char *slashDotXdefaultsDash = "/.Xdefaults-";
	int len;

	(void) GetHomeDir (fname, PATH_MAX - strlen (slashDotXdefaultsDash) - 1);
	(void) strcat (fname, slashDotXdefaultsDash);
	len = strlen (fname);
	(void) _XGetHostname (fname+len, PATH_MAX-len);
	xenv = fname;
    userdb = XrmGetFileDatabase (xenv);
    XrmMergeDatabases (userdb, &xdb);
    return (xdb);

I recommend using .Xresources loaded into the xrdb at start time.  It
makes the most general sense to me.  That way customizations are a
property of your $DISPLAY and not a property of your $HOME.  But
either works if you understand the search and merge order.


Attachment: signature.asc
Description: Digital signature

Reply to: