But if the above edit achieves the same startup behaviour as that
shipped with 10.5,
one has to ask _why_ did 10.5 use a new socket?
Probably, the most compelling reason was automatic handling of
multiple users. Launchd supports SecureSocketsWithKey, which generates
a random socket path and sets an environment variable. However, the
SockPathName takes a fixed name. org.x.X11.plist would have to change
per-user with the hard-coded path.
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. 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.
What is _gained_ my using an alternate socket, that could not have
been achieved
without it. Similarly what is _gained_ by defining a new
interpretation for DISPLAY,
that could not have been hidden in the x11 transport library?
So far all I can see is that two other programs (xauth, ssh) had to
be updated
to cope with the new DISPLAY contents.
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. 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. It's bad programming practice to take into your
own hands what has already been provided in a standard API. You only
run the risk of introducing bugs. If you can improve the mechanism
behind the API, you should do so as a patch to the original library,
not as some maverick localized implementation.
--
Andrew J. Hesford <email@hidden>
Department of Electrical and Computer Engineering
University of Illinois at Urbana-Champaign
_______________________________________________
Do not post admin requests to the list. They will be ignored.
X11-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/x11-users/email@hidden
