"Charles T. Smith" writes:

> If it resides on the client-host ... (where the application is running)
> ... why is it different than .Xdefaults?

Presumably to let you have different defaults on different
X client hosts that mount the same home directory via NFS.

The XENVIRONMENT variable is read by InitDefaults() in
libX11/src/GetDflt.c, viewable at:
http://gitweb.freedesktop.org/?p=xor...GetDflt.c#l176

In comp.windows.x, Charles T. Smith

wrote
on Sun, 01 Apr 2007 16:01:56 +0200
:
> What is the function of the .Xdefaults-hostname file?
>
> By way of background, the X man page says:
>
> XENVIRONMENT
> ... If this variable is not defined, a
> file named $HOME/.Xdefaults-hostname is looked for instead,
> where hostname is the name of the host where
> the application is executing.
>
> What this doesn't say is *where* the file is. Does it reside on the
> client or the server?

The client.

>
> If it resides on the server-host, it could inform the server about
> client-host specific things - I can't think of any off-hand, but I'm sure
> it could be useful.
>
> If it resides on the client-host ... (where the application is running)
> ... why is it different than .Xdefaults?

There is the possibility that the home directory could be mounted by
several hosts (e.g., NFS server). That's at least useful.

>
> Are all members of the set .Xdefaults-hostname actually synonyms for
> ".Xdefault-remote"? Because truss(1) tells me xterm(1) reads exactly
> that file, .Xdefaults-hostname, no matter what remote it paints its window
> on.
>
> And, how do I tell my clients when I'm on my cygwin/laptop that they need
> to paint different windows than when I'm on my linux/desktop?
>
>
> Also, is it true that .Xdefaults-hostname is not processed by cpp?
> (maybe there's related logic there)?
>
>
> Are these two files documented in any other man pages?
>
> Thank you, folks.

I'll admit this is new to me, and I've been using X for awhile.
However, .Xdefaults has been around for awhile as well; that's why I
know it's on the client, and in any event truss proves it.

--
#191, ewill3@earthlink.net
Useless C++ Programming Idea #7878218:
class C { private: virtual void stupid() = 0; };

--
Posted via a free Usenet account from http://www.teranews.com

On Sun, 01 Apr 2007 10:31:08 -0700, The Ghost In The Machine wrote:

> In comp.windows.x, Charles T. Smith
>
> wrote
> on Sun, 01 Apr 2007 16:01:56 +0200
> :
>> What is the function of the .Xdefaults-hostname file?
>>
>> By way of background, the X man page says:
>>
>> XENVIRONMENT
>> ... If this variable is not defined, a
>> file named $HOME/.Xdefaults-hostname is looked for instead,
>> where hostname is the name of the host where
>> the application is executing.
>>
>> What this doesn't say is *where* the file is. Does it reside on the
>> client or the server?
>
> The client.
>
>>
>> If it resides on the server-host, it could inform the server about
>> client-host specific things - I can't think of any off-hand, but I'm sure
>> it could be useful.
>>
>> If it resides on the client-host ... (where the application is running)
>> ... why is it different than .Xdefaults?
>
> There is the possibility that the home directory could be mounted by
> several hosts (e.g., NFS server). That's at least useful.
>
>>
>> Are all members of the set .Xdefaults-hostname actually synonyms for
>> ".Xdefault-remote"? Because truss(1) tells me xterm(1) reads exactly
>> that file, .Xdefaults-hostname, no matter what remote it paints its window
>> on.
>>
>> And, how do I tell my clients when I'm on my cygwin/laptop that they need
>> to paint different windows than when I'm on my linux/desktop?
>>
>>
>> Also, is it true that .Xdefaults-hostname is not processed by cpp?
>> (maybe there's related logic there)?
>>
>>
>> Are these two files documented in any other man pages?
>>
>> Thank you, folks.
>
> I'll admit this is new to me, and I've been using X for awhile.
> However, .Xdefaults has been around for awhile as well; that's why I
> know it's on the client, and in any event truss proves it.


Okay, I guess that's just the way it is.

This all started when somebody on the fvwm mailing list suggested to me
that a way to have different colored frames, depending on the client-host,
was to start them with the -class property and then set different styles
in the fvwm config file for different classes. Great idea which caused
havok with my .Xdefaults file.

So I had this great idea to have a different .Xdefaults-hostname file for
each server... or to use cpp mapping of the same base file. oops... both
wrong.

I guess I'll just have to have a lot of redundant definitions in my
..Xdefaults-hostname file.


On the other hand, maybe it would be quick and easy to define and
implement a new convention ... like .Xserver-hostname. Or, to add cpp
processing to .Xdefaults-hostname.

"Charles T. Smith" writes:

> On Sun, 01 Apr 2007 10:31:08 -0700, The Ghost In The Machine wrote:
>
>> In comp.windows.x, Charles T. Smith
>>
>> wrote
>> on Sun, 01 Apr 2007 16:01:56 +0200
>> :
>>> What is the function of the .Xdefaults-hostname file?
....
> This all started when somebody on the fvwm mailing list suggested to me
> that a way to have different colored frames, depending on the client-host,
> was to start them with the -class property and then set different styles
> in the fvwm config file for different classes. Great idea which caused
> havok with my .Xdefaults file.

You should have been advised to use -name or -title (can't remember
which). Fvwm matches on more than one property.

"Charles T. Smith" writes:

> On the other hand, maybe it would be quick and easy to define and
> implement a new convention ... like .Xserver-hostname. Or, to add cpp
> processing to .Xdefaults-hostname.

You can use #include. See XrmGetFileDatabase(3X11).