🚀 go-pugleaf

In article <7880@baird.cs.strath.ac.uk>, amurphy@cs.strath.ac.uk (Allan Murphy CS4) writes:

> Is there a standard technique / bit of code that X applications are
> supposed to carry out when the user specifies a display other than
> $DISPLAY ?

I haven't seen anything noteworthy - just use the specified string in
the XOpenDisplay call instead of the default.

> At the moment, my app. tries a straight XOpenDisplay, then if that
> doesn't work, it tries the following :
>   assume the remote machine name is the display name ( possibly -":0.0" )

Remote machine name?  What remote machine name?  I thought we were
assuming the user specified an alternate display name, not machine
name.

>   rsh to the remote machine and do an xhost +local machine name

Aaak!  Applications should never touch the access list except on
explicit user command (eg, xhost).  Doing something like this behind
the user's back strikes me as about as antisocial as silently changing
the user's .cshrc/.profile/.mailrc file.  If I found an application
doing this, I would report it as a bug.  If I couldn't fix it and the
vendor refused to fix it, I would kludge a workaround, by patching the
binary if necessary.  (I would much more probably give up on trying to
use the application altogether, on the theory that I could never trust
that it wasn't silently corrupting some other piece of my environment.)

Besides, it will fail often enough that it is of questionable value in
any case.  The remote machine may not be running anything UNIXish (eg,
an X terminal); the local machine may not trusted (in the rsh sense) by
the remote machine; the local username and the remote username may
differ; there may be a packet fence between the machines that forbids
rsh but not X; the open may be failing for a reason other than the
access list being wrong; the display string may be something new that
doesn't have a machine name to rsh to in it; etc....

> Is there a bit of Xlib code to do this correctly / easily / more
> sensibly / more portably / realistically / so that it will work under
> different window managers ?

The window manager has nothing whatever to do with this.

					der Mouse

			old: mcgill-vision!mouse
			new: mouse@larry.mcrcim.mcgill.edu