main discussion list for development topics

Henning Makholm | 1 Apr 2004 01:26

Re: Accepting .Xdefaults by default

Scripsit Jacobo221 <jacobo221 <at> hotmail.com>

> Currently, Debian doesn't support ~/.Xdefaults but does support
> ~/.Xresources. The ways to walk around this are to soft link or to change
> it's name.

Beware! The intended semantics of .Xresources and .Xdefaults is *not
the same*!

.Xresources is meant to be loaded into the X *server* when a user logs
in. It will affect all clients started during the X session, even
clients running on remote machines.

.Xdefaults is loaded locally by each *client* as it starts up. Settings
in it will affect all clients *running* on that machine and account,
even if they connect to a remote server.

Each kind of settings is useful, and I daresay that there are Debian
users out there who depend on the ability to define either kind of
settings - even though the vast majority are probably not aware of the
difference, and many of them misuse the files because they don't know
the difference.

If you read the manpage X(7x) you'll find that Debian does not use the
name .Xdefaults bu default, but instead .Xdefaults-<hostname>. That is
presumably intentional. You should be able to override this by setting
$XENVIRONMENT in your .profile or .login file. If that does not work
(and you're sure its not your own fault, or the individual
application's), file a bug report against libXt6.

(Continue reading)

headers

Branden Robinson | 1 Apr 2004 08:26

Re: Accepting .Xdefaults by default

[CCing debian-x]

On Thu, Apr 01, 2004 at 12:26:23AM +0100, Henning Makholm wrote:
> Scripsit Jacobo221 <jacobo221 <at> hotmail.com>
> 
> > Currently, Debian doesn't support ~/.Xdefaults but does support
> > ~/.Xresources. The ways to walk around this are to soft link or to change
> > it's name.
> 
> Beware! The intended semantics of .Xresources and .Xdefaults is *not
> the same*!
> 
> .Xresources is meant to be loaded into the X *server* when a user logs
> in. It will affect all clients started during the X session, even
> clients running on remote machines.
> 
> .Xdefaults is loaded locally by each *client* as it starts up. Settings
> in it will affect all clients *running* on that machine and account,
> even if they connect to a remote server.
> 
> Each kind of settings is useful, and I daresay that there are Debian
> users out there who depend on the ability to define either kind of
> settings - even though the vast majority are probably not aware of the
> difference, and many of them misuse the files because they don't know
> the difference.

All true.  Thanks for offering this clarification.

> If you read the manpage X(7x) you'll find that Debian does not use the
> name .Xdefaults bu default, but instead .Xdefaults-<hostname>. That is

(Continue reading)

headers

Henning Makholm | 1 Apr 2004 21:08

Re: Accepting .Xdefaults by default

Scripsit Branden Robinson <branden <at> debian.org>
> On Thu, Apr 01, 2004 at 12:26:23AM +0100, Henning Makholm wrote:

> > Debian does not use the name .Xdefaults bu default, but instead
> > .Xdefaults-<hostname>. That is presumably intentional.

> It is.  The reason is that because the application-defaults are loaded
> client-side, you may want to customize them on a per-host basis.  You
> already get this with the server-side resources because your X session
> runs out of $HOME.

Not necessarily. In fact I have accounts on three different university
sites where my $HOME is shared between all workstations and xdm
servers in the department. They all load the same .Xresources when I
log in. That would have caused me trouble if I had happened to
physically move between differently-equipped workstations often.

(Of course I know how to solve this by appropriate ad-hoc magic in
.xsession, and splitting .Xresources by hostname would not be a good
solution nevertheless, so I'm not proposing to change the default
behavior of Debian's X packages).

> > If that does not work (and you're sure its not your own fault, or
> > the individual application's), file a bug report against libXt6.

> The package's name is libxt6 (all lowercase), but yes.

Curses, foiled again! I just tried 'dpkg -L libXt6' and it worked.

--

--

(Continue reading)