[lug] X11 Protocol, migrating windows to remote displays

[Nate Duehr]

I've only read about it, but isn't this kinda what x2x does?  Maybe not...
you want the ability for another machine to "steal" stuff off the
windowmanager of another... but x2x supposedly allows you to display one
desktop across multiple X servers, right?

Caveat emptor, I haven't played with it.

Nate Duehr, nate at natetech.com

----- Original Message ----- 
From: "D. Stimits" <stimits at attbi.com>
To: <lug at lug.boulder.co.us>
Sent: Sunday, May 18, 2003 7:10 PM
Subject: Re: [lug] X11 Protocol, migrating windows to remote displays


> Michael J. Hammel wrote:
>
> > On Sun, 2003-05-18 at 18:01, D. Stimits wrote:
> >
> > >Does anyone here know the X11 protocol well enough to say how easy it
> > >would be to write an app (or modify xterm/konsole/gnome-terminal) to
> > >allow migrating an X11 terminal to a remote display *after* the app has
> > >started? I have an integrated app that I want to run entirely on one
> > >machine, but I want the multiple windows it produces to be able to
> > >migrate to/from a remote display. If I set $DISPLAY ahead of time, the
> > >entire app goes to the remote display; even if I wanted that, it would
> > >not allow me to migrate the window back to the original machine at a
> > >later time. I'd like to be able to take an ID from a visible window or
> > >widget, and tell X11 to redisplay on some other machine.
> >
> >
> > The easiest way to do this would be to have the first app fork a child
> > that displays on the remote system and has its own event processing loop
> > and then use TCP or Unix sockets to send data to the child for display
> > on the remote monitor.
>
> Herein lies the pain...I don't want to rewrite a third party app, and I
> want this to work with any app that puts out a window (or in this case,
> multiple windows). I would like it to be such that the applications
> being transferred between displays continue to run on the start machine,
> but pieces of the app display on different displays, one at a time, as
> if they were started with $DISPLAY to a remote host.
>
> >
> > If you don't want a forked child, you can connect to different remote X
> > servers using the XOpenDisplay() call of Xlib.  GDK 1.2 does not allow
> > you to do this (haven't checked 2.x yet) so you'd have to do it directly
> > from Xlib and fake gdk into doing the right thing. I have no idea what
> > Qt can do in this area since I don't do C++.
>
> It is this faking that I would like to do, but not from the original
> application. I would like a second application to essentially hijack any
> displayed widget, and proxy it to another host, without the original app
> having any knowledge of it. For example, if you use KDE (and I think
> Gnome) with multiple workspaces (view ports) on a single display, you
> can right click on the title bar of a widget and it offers to let you
> send the widget to another desktop...just another location on a virtual
> desktop. I'd essentially be adding the ability to send it to an abstract
> desktop that names not only the view ports of the current machine, but
> also the view ports of the desktop on remote machines.
>
> >
> > I'd probably use the forked child method.  If the data needs to be real
> > time then you might not want this, but if you're doing real time display
> > you probably aren't mucking with remote terminals either.
>
>
> Problem with forking is that I have to rewrite every program. I'd like
> to do things like open a browser on one machine (mozilla), and open the
> email client, then move just the browser to a remote display. Or in a
> software development IDE, to send the source code editor for one file to
> one machine, and let the source code editor for a different file stay on
> the local machine. Think of it as a poor man's Xinerama (pseudo-Xinerama
> proxy), that supports redisplay not as drag-n-drop, but as
> right-click-and-enter-display-specs. I have a second display on a second
> machine with a fast network, but it has low cpu power on the second, and
> all of the windows of the app have to work together on a single machine.
>
> D. Stimits, stimits AT attbi DOT com
>
> _______________________________________________
> Web Page:  http://lug.boulder.co.us
> Mailing List: http://lists.lug.boulder.co.us/mailman/listinfo/lug
> Join us on IRC: lug.boulder.co.us port=6667 channel=#colug
>