Re: app-defaults vs. Xresources
On Sun, 12 Jan 1997, Richard Kaszeta wrote:
> No... I am not talking about my own clients... A large number of
> accounts of my machine are accessed from sites well outside of *any*
> control of mine (well outside of *.umn.edu).
If I understand you right, the whole problem is about users who don't
perform a login via the local "/etc/X11/Xsession" (where the Xresources
are activated) but come in via "xrsh" and friends.
You address a problem that is much more general: proper configuration in
a networked environment. It begins with fundamental things like setting
the right PATH, includes the Locale-settings and ends with the Xresources.
Putting a "xrdb -merge /etc/X11/Xresources" in in the login-script might
help for the first time but is no real solution. (Of course wrapped
with an if [ "$DISPLAY" ]). Even '-merge' overwrites settings: the
default settings at the users "home" machnise. That's not acceptable.
A slightly better (temporary) solution would be to have a link in the
users home-directory: ~/.Xdefaults-<hostname> -> /etc/X11/Xresources.
But this has the disadvantage of being host-specific and you have to tell
the users to do it.
The real solution would be to add /etc/X11/Xdefaults into the list of
files which are sourced in by the (?) X-library. Just let
/etc/X11/Xresources be the file to overwrite resources for local users (as
it used to be) and the let the Xdefaults-file overwrite the resources for
the remote users.
Of course, the meaning of "defaults" are different: in "app-defaults"
there would be application defaults, they belong to a certain application.
"Xdefaults" would overwrite the application defaults to provide a default
for the X-Windows suite on that machine (and therefore the name: they
belong to X). That should be documented in the heading comments of that
files.
> Quite often I see app-defaults and Xresources files treating as
> interchangeable, and my point that they are *not*, since one provided a
> mechanism for changing the resources on the client side, and one
> provides a mechanism for changing them on the server side.
Now I remember that I read that before.
I would not take the fact that the mechanism _is_ able to provide
configuration on the server side as an argument to use it. Because it
breaks the concept of default values which is the intention of the
directory (name and permissions indicate that).
We should find a way to satisfy your needs without throwing the
current advantages away. One way would be the "Xdefaults" file as
described above.
-Winfried
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-REQUEST@lists.debian.org . Trouble? e-mail to Bruce@Pixar.com
Reply to: