[lug] X11 Protocol, migrating windows to remote displays

D. Stimits stimits at attbi.com
Mon May 19 16:18:49 MDT 2003


Michael J. Hammel wrote:

> On Sun, 2003-05-18 at 20:10, D. Stimits wrote:
>
> >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.
>
>
> The view ports are a function of the window manager, which has special
> privileges as an X client that no other clients have - only one window
> manager at a time.  The exception is when you run XNest, which can then
> have its own window manager within it, ad naseum.

The view ports are just an analogy here, they are a virtualization of a 
physically large desktop that the monitor shows only part of at one 
moment. The act of moving a widget from one virtual workspace to another 
is indeed part of the window manager environment, because the virtual 
workspaces are not really part of X11, they are display manager 
concepts. However, remote display is an X11 concept. What I'm not 
certain of is whether, having set a $DISPLAY environment at startup, 
that environment is written in stone, or if it is mutable. It would be 
possible to write an app that tries to change this for itself, possibly 
failing in error...I don't know. I'd be interested more in having 
something like a second program which examines an ID of a displayed 
window, and proxies to a remote $DISPLAY, without the original app 
knowing about it.

>
>
> >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.
>
>
> Xinerama is an extension to the X server, I think.  What you're asking
> to do is move the functionality of an X server extension and/or the
> function of a window manager into an ordinary client.  No can do, as far

Not really what I'm wanting to do, at least not exactly. Take an 
application like xprop, or anything that can view X11 information about 
a particular app. There are apps which show the ID tree of a running 
app, useful for debugging. If such things can be viewed, perhaps then an 
X11 extension (without modification of the display manager itself) could 
be used to take those values and lie to the application. The lie could 
for example change the desktop size and color depth to say instead the 
desktop size and color depth of the remote machine (the X11 server 
should be able to do this without window manager modification). Then if 
networking and auth, etc., are transparently forwarded to the remote X11 
server, maybe the app could be faked into displaying on the remote 
machine. One thing I am certain of, it would be complicated.

> as I know.  You need to write your own window manager, at a minimum, to
> try and get this sort of function, and the window manager would probably
> end up having to make use of the X server extension to do what you're
> asking.

If the X11 server itself lies to the window manager and tells one 
display manager that the app no longer exists, while telling another 
display manager on another machine that the app just started, maybe they 
would cooperate, and the displayed app (with a proxy so it never knows 
anything happened at all) would magically appear on a new desktop, 
without restarting it under a new $DISPLAY.

>
> Dragging a client from display 1 to display 2 would have to be managed
> by the window manager.  Moving a child window of the clients main window

I'm not looking for drag and drop. I'm looking for an ability to 
manually type in an IP address and display info, then click on another 
app and have information about that app extracted, then transparently 
proxied/redirected to another machine, without the app knowing.

> from display 1 to display 2 requires reparenting the child window to the
> root window of display 2 in order to get a different host machine.

Yes, reparenting if proxy is not used. I'm suggesting lying to the app 
and telling it that it has not been reparented, then using a new parent 
on the new display, with the proxy handling all lies to the app.

> Can't do that externally from the application.  It would have to be done
> from within the application as far as I know, if it can be done at all.
>
> Some apps can swallow other apps (there is an X extension for that, I
> think, or maybe its just a seldom used feature of X11R6 - its been quite
> some time since I looked at it) but as far as I know they can only
> swallow apps on the same host, not on remote hosts.
>
I'm not sure, but I think to be swallowed by another app, it probably 
has to be coded in the app itself to support it. If this is not a 
requirement, then swallowed apps would be just fine, I wouldn't mind a 
second frame around the original window when displayed on a remote 
machine. Overall, it sounds like it is going to be too painful to do.

D. Stimits, stimits AT attbi DOT com




More information about the LUG mailing list