Re: The meaning(s) of $DISPLAY (was Re: Explanation of X implementations)
Re: The meaning(s) of $DISPLAY (was Re: Explanation of X implementations)
- Subject: Re: The meaning(s) of $DISPLAY (was Re: Explanation of X implementations)
- From: Derek Fawcus <email@hidden>
- Date: Mon, 19 Nov 2007 15:42:42 +0000
On Mon, Nov 19, 2007 at 09:28:26AM -0600, Andrew J. Hesford wrote:
>
> If you think it's valuable, you can always petition Apple to add a
> feature to launchd that would let the user specify a socket name of
> the form "/path/to/socket/%d", where %d would be substituted at run-
> time with some unique integer.
maybe worth a try...
> However, except for broken X11
> programs, I would think most software that gets their socket locations
> from environment variables don't care where the sockets are located,
> since the variable contains a full path anyway. So this might be a
> case of extending launchd just to support broken X11 apps.
except it never used to contain a path...
> I don't know anything about X programming. What do clients need to do
> with DISPLAY? It would seem to me that the only thing programs have to
> do is pass the contents of DISPLAY to some X library function, which
> interprets the string and performs the action. If clients are /
> required/ to process and understand DISPLAY, that amounts to a lot of
> duplicated efforts (in every X client!) for no gain. This would be a
> serious design flaw, since DISPLAY can point to anywhere.
Normal X programs will not since they will use a library.
However there is one case that will, that is because X defines a
wire protocol, and if one wants to shim / proxy the protocol then
one really wants to connect to the socket end point.
It is nice to be able to do that without requiring that the server
listen on a TCP port.
(As an example. I have been intending to create such a program
that would connect to /tmp/.X11-unix/:%d (or /tmp/.X11-pipe/:%d
on solaris) specifically so that it could do such proxying.)
> If the X
> libraries DO provide the necessary routines, then shame on the
> developers of these applications for not sticking to the standard API
> for manipulating X11.
Actually the normal X library is poor anyway; but given that X
is defined as a protocol - one should be able to get to the protocol
end point without having to pull in loads of external dependancies.
The obvious example is proxying X over SSH with the local endpoint
server/client ports being unix domain sockets rather than TCP sockets
as tends to be used now. (and that is probably why the ssh client
parses DISPLAY).
DF
_______________________________________________
Do not post admin requests to the list. They will be ignored.
X11-users mailing list (email@hidden)
This email sent to email@hidden