[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