Move application between desktops?
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.)
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.
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...
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")
Really not sure if that's going to work...but it's *bound* to leave an interesting mark!
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...)
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?
...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.
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!
The OP wants to transfer applications between $DISPLAY entities, not simply from one virtual desktop to another.
Definitely yes - within the same $DISPLAY, just between virtual desktops, it's very easy :o)
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.
Eh...sorry about the misread...
Best of luck getting the answer!
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.
It is possible
Hi, I realise this is a late response, but thought I'd throw it out there anyway.
It can definitely be done, the framework is there, but I haven't yet figured out how to do it for arbitrary apps. If you download the GTK examples package, and run gtk-demo, you'll find `Change Display' in the list on the left. Double click to run the example app. This can be used to move the GTK examples app from one display to another, but for me it didn't work on any other apps.
Just thought I'd poke in to say it can be done, just not sure how.
Solution to enable X application mobility between screens
shifter & xpra solve this beautifully.
shifter is a graphical helper applet, xpra is the abstraction layer between the X app and the X display which mobilises the X application.
use your favorite search engine to get more details.
I'll be looking into this myself at some point here.. If it works 'as advertised' then this would/could (a big *maybe*) act as the "missing link" as far as not being able to drag apps from one screen to another while in TwinView mode (nvidia). Long story short (re: my nvidia hardware):
TwinView: works with compositing
TwinView: does not allow dragging apps from screen to screen.
Xinerama: does not work with compositing.
Xinerama: allows dragging apps from screen to screen.
Of course, this invites another unfortunate question: why do we need a(nother) separate X-related tool/application to do this? Jeez.. Oh well.. Maybe one day there'll be an X that has all its pieces & functionality contained within one unit..
The "xpra" seems to work as advertised. I think there is further work required for shifter as although on the surface it does the job, it seems to struggle with a terminal server having thin clients, users logged on in 2 locations etc. The core seems up to this, maybe just needs some user testing & feedback. I will share here if I get shifter to do what I need. Hopefully it will address your Twinview issue.
I can drag apps between my monitors with TwinView - are you sure you can't? Are you using TwinView or separate X screens?
|All times are GMT -5. The time now is 12:02 AM.|