Linux - DesktopThis forum is for the discussion of all Linux Software used in a desktop context.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
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.
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!
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...)
...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...
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
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.
I am nowhere near that. I am not even reasonably knowledgeable about xlib. However, I can answer, I think.
Quote:
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?
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.
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.
This sounds very interesting! I hope the OP is still around and has a chance to read this update, and maybe report if they have made any progress in this area since their last post..
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.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.