devdol

[Log in to get rid of this advertisement]

A challenging question to the real gurus of X:

Is it principally possible to "move" a running application's window live to another $DISPLAY (without killing and restarting the app, of course)? If so, by which means?

Possible scenarios to illustrate the need for this (incomplete list):

1) User A and B are logged onto a PC on parallel sessions, lets say DISPLAY=:0 and DISPLAY=:1.0. A wants to hand over some running application (window) to B, in terms of permissions: B and A mutually agree to transfer this applications between their window managers.
(Maybe there is even an analog flag to the "on all desktops" feature on virtual desktops within a session?)

2) User X is logged on interactively on a $WINDOWMANAGER's session. $WINDOWMANAGER crashes. X starts a second parallel session and wants to save some data he just worked on unsaved yet.

3) User Y is logged on interactively, locks his session, moves to another location and reconnects to his workstation using a tunneled vnc session, which by default throws him to DISPLAY=:32.0. Maybe he wants to "fetch" his running mail client, which he left with some unfinished messages open...

And so on. Certainly (1) is more complicated, as different users normally cannot be owner of the same process and something like "chown" onto that process would be necessary, too. However, in scenario (2) and (3) there should not be no problem in terms of permissions.
They might differ, as far as the same or different window managers might be active on the different DISPLAYs.


B.t.w. - Yes, I know VNC, RDP, NX and so on, but that's not what I asked for. (They export a whole session, not a single, specific application running on them.)

xeleema

Just a wild stab in the dark, but here goes;
If it's possible to change the environment variables of a running process (somewhere in the /proc tree?), then this might work;

1. Find the Process ID (PID) of the X-based application, then issue a "SIGSTOP" ("kill -SIGSTOP pid#"), which should effectivly 'pause' the application.
Basically just
2. Change $DISPLAY for that PID's environment.
3. Issue a "SIGCONT" ("kill -SIGCONT pid#")to the PID and see if it freaks and jumps to the new display...

UPDATE:
Alright, after a bit of reading, let me revise those steps;
1. Fire up the GNU Debugger ("gdb")
2. Run the following;
(gdb) attach process_id
(gdb) call putenv ("DISPLAY=your.new.value:here")
(gdb) detach
3. ???
4. Profit!

Really not sure if that's going to work...but it's *bound* to leave an interesting mark!

devdol

That's a quite fascinating proposal. Thanks!

However, when I try to move an running thunderbird from :0 to :32.0, it remains where it is - independent of having it SIGSTOPped before and SIGCONTinued afterwards or not.

Furthermore, wmctrl, invoked on :32.0, always only "sees" windows on this display.

Hence, I suppose, in addition to a change of $DISPLAY in the target application's environment, it may be necessary to "deregister" it somehow from it's former window manager and "register" it to the new one - as those window managers eventually manage the window.

And perhaps, if one finds a way to execution this de-/re-registration sequence, $DISPLAY might be changed implicitly.

(Hopefully, this observation may arouse another X/wm adept...)

xeleema

At this point, I think we're going to need to clarify the technical details of your situation.

What Linux Distribution are you running? (and what version?)

Is it just Thunderbird you're trying to move? (and what version?)

Both users are connected to the same server, correct?

devdol

...it's Debian GNU/Linux squeeze/sid running a 2.6.26 kernel and xserver-xorg 7.4+3, but there should be a solution independent to those details.

In the test mentioned above, I tried to move a running iceweasle-bin from :0 (managed by KDE 4) to a vnc desktop on :32.0 (managed by icewm-lite). Again, it should be quite independent from the application, as the different window managers may care for it's window, and one and the same X server displays them.

linusr@flanders

Ehrm...I do this all the time - move stuff from one desktop to the other. Just drag the thing.

Open a program on desktop 1. See the four desktops @ the right-below? The first one should display a little squarelet/shape. Ok, perhaps you can now switch to annother desktop. Moving the application is as simple as clicking on the desired desktop-icon (right-below). Now, bring the mouse over the shapelet that represents your application and hold-and-keep the mouse button down, drag and release where needed...

Hope that this is your "aha" !!!

Wellness 2 U!

Thor

GrapefruiTgirl

If I'm not mistaken, you've misunderstood the question, though I must admit, when I first read it, this is what I thought too.

The OP wants to transfer applications between $DISPLAY entities, not simply from one virtual desktop to another.

Sasha

devdol

Definitely yes - within the same $DISPLAY, just between virtual desktops, it's very easy )

Nevertheless, thank you all for your replies!

Moving windows between different window managers seems to be a challenge on X11-level. Didn't find out yet which tool to use for that.

linusr@flanders

Eh...sorry about the misread...

Best of luck getting the answer!

Thor

i92guboj

I am nowhere near that. I am not even reasonably knowledgeable about xlib. However, I can answer, I think.

No.

Long answer: while technically possible in theory, no application supports this. For this to possible, the feature would need support in both the X server and the application itself. So, applications as they are now wouldn't work even if X supported such a thing, at least this is my understanding.

The application would need to be able to "detach" itself from a display, and from it's own UI, which would die an horrible death, then the UI would need to be recreated and the core of the application re-attached to the new UI we just created, then a new window would need to be created around the application (there's absolutely no way that you can just transfer a window from wmX running on display :0.1 to wmY running on :0.0

Much like a server/client thingie, like if the core of the application was some kind of daemon or so. There's an irc client for qt4 that can do a similar thing like screen does for text sessions. I think it was called qassel or something like that.

I have no idea if there's any mechanism in X to communicate two sessions, via dbus or whatever. If that doesn't exist, it would need to be implemented as well, so sessionX can tell to sessionY:

"hey, attach appCoreX to a new window inside yourself and let the application know that it must re-render it's UI, then let me know how it went so I can kill the UI here"

As you see, technically possible, but, as far as I know, there's no infrastructure for this yet, and applications would need to support it (or at least, it would need support at toolkit level, then all apps made with a given toolkit would inherit the capability).

This is all just thinking aloud, as I said, I am no guru on the X internals.