[lug] X11 Protocol, migrating windows to remote displays

[D. Stimits]

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