Transfer display of active windows remotely

[Prasad H.L.]

--- On Sat, 10/11/08, Matthieu Herrb <matthieu.herrb at laas.fr> wrote:

> Magnus Kessler wrote:
> > On Saturday 11 October 2008, Prasad H.L. wrote:
> >> This is what I have in mind.
> >>
> >> - Consider display :0 on machine 1 (m1) and
> display :0 on machine 2 (m2).
> >> - Let us say, a process 'p1' running under
> privileges of user 'u' opens a
> >> window on :0 of m1. - I do an 'ssh -X
> u at m1' in xterm on :0 of m2 and
> >> login to m1.
> >> - Now, from that xterm window, is there any way by
> which I can make that
> >> window of process 'p1' appear on :0 of m2.
> >>
> >> This kind of situation regularly occurs to me and
> some of my friends. We
> >> have multiple terminals at our disposal. On one
> terminal, I start some
> >> xterm which is, let us say, showing output of some
> process. I go to some
> >> other department in the institute and do an ssh to
> that terminal. Now, I
> >> have no way of seeing what is going on in that
> xterm. Well, this is a
> >> simple example, of course.
> > 
> > This particular use case, seeing the terminal output
> of a process on a 
> > different terminal, can be achieved quite easily using
> "screen" [0]. No 
> > support from X required at all.
> > 
> > In a first terminal (or even on the console without
> any X) run screen. Then 
> > run any non-graphical process in the screen session.
> When you move to a 
> > different computer, log into the first one through ssh
> and grab the screen 
> > session (screen -dr). You will see the output of the
> still running process 
> > there.
> > 
> >> Another example (though childish). Consider a case
> where I have a browser
> >> window with many tabs open in it, the window being
> displayed on :0 of m1.
> >> I would like to export it to :0 of m2 when I go
> and sit in front of m2.
> >> Before closing ssh on m2, I re-export the window
> back to :0 of m1 and
> >> then quit the ssh. Such a feature would be really
> great to have. Since,
> >> any way, currently the only dependency on the
> remote machine is that it
> >> should have an X server running, I believe this
> feature should be
> >> implementable if not already present.
> > 
> > Have you looked into NX [1]? NX can be considered the
> "screen" for running X 
> > sessions. I usually run an NX session on one machine
> (in the background, 
> > without any access to the graphics hardware), then
> connect to it using the 
> > nxclient software from either machine on the network.
> I can disconnect from 
> > a running session and pick it up later from somewhere
> else.
> > 
> 
> In addttion to NX or other similar setups (using Xvnc for
> instance), Let 
> me add that there is nothing anymore in the X protocol that
> prevents 
> doing what Prasad H.L. suggests directly (without a proxy).
> 
> It is an application (or maybe toolkit) level problem:
> handle the event 
> that the X display connection is being closed better than
> by killing the 
> application and allow it to reconnect to a new display
> later (through 
> some communication protocol).
> 
> The gnuserv/gnuclient code in XEmacs for instance
> implements that (with 
> some bugs and limitations, but it works for me everyday).
> I've heard rumors that Gtk and/or Qt have support for
> this kind of 
> things. It's just application that fail to implement
> the required support.
> 
> With Xft and XRandR the 2 major difficulties that may have
> prevented 
> more applications to implement that in the past are gone.
> 
> It would definatly be nice to see more apps supporting
> that, but I don't 
> thing that Xorg can do a lot in this area.
> -- 
> Matthieu Herrb

Your explanation is quite informative. I did not know this aspect about X server. My only point was, if support for such a switch of window display exists at a basic level then irrespective of whether the application bothers or not, the switching between X sessions can be made seamless.

With Regards,
Prasad H. L.