On 24-Jan-02 Andrew Savory wrote:
On Thu, 24 Jan 2002 Ted.Harding@nessie.mcc.ac.uk wrote:
How to transplant X windows from machine to machine?
I'm fairly sure this can't be done in the way you describe, as disconnecting the display on "B" will result in the application believing it has no display, which would cause it to quit.
Well, while I do strongly suspect that it can't be done, it's not for this reason.
I reckon it's _logically_ perfectly possible; it's just that a comprehensive solution would probably be so complicated that no-one has implemented one.
Consider how X works, taking the "xterm" app as a simple example.
1. User logs in to A from B and starts xterm at A.
2. xterm at A binary starts up, picks up $DISPLAY = B:0.0
3. xterm at A opens X connection to X server at B
4. xterm at A sends X requests to X server at B (please open a window, ..., please do the following in the window ... ); X server on B implements these. ...
5. User finishes with xterm and "closes" it from B; whereupon:
6. xterm at A requests X server at B to demolish display of xterm
7. xterm at A closes X connection with B
8. xterm at A exits
Now suppose that, at 4 above, User moves from B to C, and logs in to A.
Suppose User at C could:
5'. send a message to xterm at A which causes it to do the following:
6'. xterm at A requests X server at B to demolish display of xterm
7'. xterm at A closes X connection with B
2'. xterm picks up new $DISPLAY = C:0.0
3'. xterm at A opens X connection to X server at C
Thereafter as at 4, 5, ... above with "C" in place of "B".
There's nothing _logically_ impossible about this, and it entirely bypasses the problem you raise (that closing the xterm window in B pulls the chair from xterm at A), since it would be xterm which caused the window to be closed, and it would still be running and about to do something else (namely switch the session to a new window at C).
However, this does depend on the existence of a mechanism for sending such a message. I'm pretty sure there's no such thing in X generally, though I can see how one might program a particular app to respond in this way if it received a certain interrupt.
I suspect the reason it hasn't been implemented in X generally is that, while it looks simple in the above example, it ain't that simple for many apps. In particular, many apps spawn subsidiary apps which open their own windows, and which ... And some of these subsidiary windows might be displaying apps which have been started in other machines D, E, ...
Unwinding that lot and switching it all to a new machine might be a tad tricky.
Otherwise, it would be handy and entirely in keeping with X's "network transparent" philosophy (i.e. you can expect to work on any machine with apps running on any other machine as if all were taking place on the machine you are at), so you'd expect that the X people would have contemplated it. If, having contemplated it, they haven't done it, there is surely a reason ...
One way I *have* done this in the past is with VNC. Run a VNC server on machine "A", and VNC viewers on "B" and "C". This means you are continuously running the application on machine "A" but you can look at it wherever you like.
Thanks (also to Robert Tillyard) for this suggestion. I must admit I've contemplated getting to know VNC -- I have a friend who uses it happily in a mixed environment of Linux & Win machines.
However, it involves much heavier load on the machines; the solution I was asking about would only involve a small overhead to do what is described at 6', 7', 2' and 3' above.
But, while on VNC-like ideas:
Another marvellous utility which I /have/ used is "xmx" ("X multiplexer"), though it's a good while since I picked it up -- I don't know whether it's still around, still less whether it has moved on.
With this, you start xmx on A, and you can nominate any other machines on the network to be "guests"; and for each you can nominate whether it will have equal input rights to A, or none ("watch-only"), or "hand-up" rights (user at B can request input rights).
Then an X window opens in A, and a mirror of it opens in all guests, within which is running an X session with its own WM (rather like xnest). Any machine with input rights can start new apps on A, whose windows appear on all guests. All machines with input rights have identical control over the apps (all running on A). So User_A moves his mouse -- all guests see the movement. User_B (with rights) moves his mouse -- ditto. User_C (with no rights) can only sit and watch. Keyboard input likewise.
As you might guess, this was developed for classroom use in a teaching Lab of networked machines.
While I've not used it for that purpose, I have used it with co-workers on other machines all working on the same project; this can be a, say, exciting experience. It gets even more exciting when you're all simultaneously editing the write-up.
Unfortunately, it has some constraints on display parameters, in particular only 8bpp or 32bpp depth, and all machines must be running X at the same bpp depth. As it happens, my present setup does not lend itself to conveniently going along with that (I can only get 32bpp on one, and I certainly don't want to tie them all down to 8bpp).
Anyway, an interesting area for discussion even if if didn't lead very far!
Best wishes to all, Ted.
-------------------------------------------------------------------- E-Mail: (Ted Harding) Ted.Harding@nessie.mcc.ac.uk Fax-to-email: +44 (0)870 167 1972 Date: 24-Jan-02 Time: 19:11:02 ------------------------------ XFMail ------------------------------