xpra seems to get a little confused when used on a system with multiple desktops and xpra managed windows on more than one desktop. (I have seen this behaviour on all 0.8.* builds. When I went back to 0.7.8, the problems did not appear.)
It seems that xpra isn't aware of desktop changes until something causes a change in window state.
I spent some more time playing with older versions of the client to narrow down when the problem appeared.
0.7.8 handled multiple desktops fine 0.8.0 shows the bad behaviour
Thanks, that narrows it down quite a bit.
I'll try to reproduce this asap.
First, the reason why 0.7.x and earlier behave differently is because 0.7.x did not try to preserve workspace mappings for each window, this is a new feature in 0.8.x, see: #170 for the feature request and associated changesets. The code works by waiting for the window to be mapped/shown, then sending it a request to move to the desired desktop/workspace.
This workspace setting/changing is only ever done if we know what workspace the window should be on, that is if the window has been configured/mapped on a client before. Now, it is possible for the window to be "configured" on the client (which will then record which workspace it is configured on) before it is mapped (which will then try to honour the workspace mapping) - but why would the workspace be different between those two events?
I really do not understand what is going on here.. Maybe you can help:
xpra attach ... -d all |& grep workspace" to see what happens (r2736 adds some extra workspace debug logging)
I assume that when you mean "start XXX on desktop YYYY" you don't mean to say "attach xpra to an existing session..."?
Hah, silly me, can you try r2737 to see if it helps?
Also, when I tested with cinnamon/gnome3, we don't get map events as expected when the windows are moved, so we don't notice that they have moved.. I'll need to think of something for this case. (maybe
PropertyNotify can help here?)
One detail I forgot to mention is that I am running KDE at the client.
I've tried a number of apps - xterm, xclock, and they all misbehave. I have moved to 0.8.5 and the problem is still there.
When I'm referring to "start XXX on desktop YYY", it is all within a single xpra session. I start two terminals, one on each desktop, and then issue commands from the terminals to start the applications that create the windows.
The file xpra.debug contains the requested output as I followed (roughly) the steps in my initial report. (r2737 didn't fix the problem.)
As an aside, after my last repro, I had a bunch of windows on desktops 2 and 3. When I dropped my xpra connection and reconnected, all the windows appeared on desktop 2.
As an aside, it looks like r2737 causes problems with pop-up windows (e.g. right click menus) when used with multiple monitors. When a pop-up menu appears, it always appears on monitor 1, even if the base window is on monitor 2.
The problem does not appear with pull-down menus.
When I reverted to base 0.8.5, the problem went away.
Hah, I didn't test on multi-monitor setups, but the r2737 change should not make things worse - so it sounds to me like we have a case where we detect the current monitor and send the information back to the server, then when we actually map the window we find the value is set and try to honour it (why it is different at this point is beyond me) - doing so is what causes the problems - maybe we need to detect the current monitor as well as workspace so that is preserved too.
Another way of saying it: r2737 is still good, what is bad is that we somehow find that the window is not shown on the display (x11 display, not "monitor") we expect it to be on (but from what you are saying, it is), so we then try to move it where we think it should be (and that's probably what causes it to move to the wrong monitor).
Does this help?
If not, can you tell us more about your setup? Is it just a plain xinerama display? Or some is it handled by the graphics card driver? Can you post:
I don't have a dual monitor setup to test on atm...
I think I've been hit by this bug today in Xpra-0.8.5. I was working from my usual PC on Desktop1 for some time. Then I attached to my session from another PC where (I think) I was working on Desktop2. After returning to first PC and attaching session I couldn't find any windows on active Desktop1 -- only tray icons appeared. Clicking tray icons did not help and only after some time I realised that everything opened in hidden Desktop2. I didn't have a chance to try fixes from comment11 but I hope this feedback add some information about this bug. After dragging windows to Desktop1 when I click File-->New, new document window still opens in Desktop2, not on Desktop1 where application is. It's all started only after attaching from another PC. Both PC's are running KDE and this bug was not present in versions prior to 0.8.0.
xpra attachopen all windows on current Desktop-1 (expected).
xpra attach-- all windows opened on current Desktop-2 (expected).
xpra attach-- all windows opened on Desktop-2 (unexpected, current is Desktop-1).
There is a misunderstanding here: the code is supposed to preserve the workspace the windows were on. So when you say:
Disconnect, drag terminal emulator to Desktop-2, switch to Desktop-2, xpra attach -- all windows opened on current Desktop-2 (expected).
That is wrong. The windows should have appeared on Desktop-1, where they were before. This is fixed in r2799 (was a sort of a "off by one" error: we never restored windows to their original desktop if it was the first one, aka "0" since this is "base 0" - confusing isn't it!)
This time, it is correct: the windows are restored on the desktop they were last seen on. (and this is still the case with latest trunk)
Please confirm and I will close this ticket and apply to the 0.8.x branch.
I will check r2799 indeed but if I understood your explanation, Desktop preservation is wrong and soon enough it will be reported as bug if not by myself then by somebody else. It is so obvious I feel awkward explaining it. When application is started it should open on current desktop. Otherwise it is a misfeature or usability bug. I didn't check freedesktop standards but I'm sure it is against best practice and likely against usability guidelines too. I know no application that would start on inactive desktop whatsoever.
Specifically regarding Xpra, such behaviour as "desktop preservation" is very confusing and counter-productive when session is attached from different computers with different Desktop configuration. Sticking apps to a particular desktop and restore 'em there is wrong, especially as it is implemented now when I can't even move apps to another desktop because they still think they run on desktop where Xpra put them and open all their dialogs not on active desktop where main application windows are but on invisible desktop!
Moreover I have different number of desktops configured on my PCs and using them to attach to single Xpra session is a terrible mess now.
I'll try r2799 ASAP but if desired behaviour matching my description then please reconsider or at least make this "feature" configurable and preferably disabled by default. Thank you.
Tried 0.8.5+r2779+r2780+r2782+r2799. I'm very disappointed. It is looks like Xpra tries to put applications to the very desktop where they've been. However as I mentioned already it is wrong and it doesn't even work well:
It is causing havoc on task bar where application buttons appear but if clicked, desktop is switching and taskbar button disappears from one desktop and appears on another.
Itis very inconvenient to move apps to the desirable desktop after attaching but even this doesn't work as expected -- when I move one app. to another desktop it doesn't stick there but moves back to original desktop (to other applications) on next attach. When I moved
kmail to another Desktop and clicked "New email" twice, two windows were opened on different desktops!
Horrible, unnecessary mess... :( Sorry, I miss "good old days" of 0.7.8... :(
One man's feature request is another's "bug". Some clarifications:
When application is started it should open on current desktop.
That is always the case. Nothing has changed here. It is only when you disconnect and then re-connect that the windows will be re-mapped to the workspace they were on previously - and only if connecting from the same client machine.
.. misfeature ... usability bug .. against usability guidelines ... start on inactive desktop
See above, that is not the case. If it was, that would be a bug.
... confusing ... counter-productive .. from different computers with different Desktop configuration
As I said above, this only applies when connecting from the same computer.
Sticking apps to a particular desktop and restore 'em there is wrong
That is a matter of opinion.
I can't even move apps to another desktop because they still think they run on desktop where Xpra put them and open all their dialogs not on active desktop where main application windows are but on invisible desktop!
First I have heard of this. Why isn't there a bug report? It's very hard to fix things we don't know about.
Each client PC should have its own workspace mapping. Maybe you aren't using all the fixes I posted?
I'm very disappointed
Well, I am very unhappy about the tone of your messages. That makes two.
it is wrong and it doesn't even work well:
It is causing havoc on task bar where application buttons appear but if clicked, desktop is switching and taskbar button disappears from one desktop and appears on another.
Another issue I was not aware of, which is not detailed enough for me to do anything about.
Horrible, unnecessary mess.
I miss "good old days" of 0.7.8
Feel free to maintain that because I won't.
Feel free to file a bug to add a
I added r2737 to set of patches applied to 0.8.5 (in case I missed something important). Nothing changed.
Another problem that I've noticed is in Firefox: when moved to another desktop it disappeared from it when one of its plugins shown dialog on invisible (inactive) desktop which probably dragged main window there. I hope you would agree that windows randomly jumping between desktops is a bug and a nasty one.
It is true that one man's feature may be another man's bug. However in this case we have a whole bunch of regression bugs that I'm not sure if I have enough time to properly report and troubleshoot, considering how much time it took me to go through testing of all 0.8.x release up to 0.8.5...
I think it would be better to disable "sticky desktop" mis-feature and perhaps add such experimental functionality as disabled by default, so it probably should be "--preserve-workspace". I hope this mess could be addressed here without multiple bug reports. Thank you.
Apologies for the tone of my messages. I know you're doing your best. It's just so frustrating to stumble upon that many issues at once when it's late and other priorities demand the little precious time...
Please don't cherry pick patches from trunk on top of an older version, the patches need to be applied to both client and server and the only sane way of testing this is to run trunk.
when moved to another desktop it disappeared.. agree is a bug and a nasty one
I don't understand how to reproduce, so I won't agree to anything. New, never seen before windows will always be shown on the current desktop, that was the case before, and still is the case.
whole bunch of regression bugs
Again, I don't know what those bugs are, or if they are regressions.
mis-feature... I hope this mess ... experimental functionality
Totally unhelpful choice of language.
..without multiple bug reports
Since I don't have clear steps to reproduce any of those supposed bugs on current trunk, things are unlikely to move very fast.
I'm trying trunk r2802 now... It is too early to report success but it appears to be better when I upgraded both client and server. I can't reproduce
kmail windows opening on invisible desktop which is good.
However in my case applications are stick to Desktop-2 and re-appear on Desktop-2 after re-attach even if I move the to Desktop-1 before disconnection.
I'll report more details later.
Important: applications need to be mapped to a desktop before we know they are there.
Simply moving them to a desktop using window manager controls is generally not enough, one has to visit that desktop at least once for the local window manager to map the window there (show it to you). Until then, as far as any application is concerned (including xpra), the window is just not shown anywhere, so the workspace mapping will remain what it was when the window was last shown anywhere. This may well be what you are reporting there.
Interesting. Somehow it is more than just visit desktop needed. Thanks to your hint I finally managed to move application to another desktop so it will stay there on next attach, but only if I moved application window within desktop after dragging moving to another desktop. Simply switch to another desktop or even work with application for some time is not enough for it to stay on this desktop on next session attach unless its window was moved.
Hah, ok, that's a DE thing, my DE unmaps windows when they get moved then maps them back when I see them again on a new desktop, compositing window managers may not do that (maps them once, then changes the property only without sending a configure event, moving them always fires a configure event so we spot the desktop change then).
Can you post the client's output with
-d all of just when you move the window to another desktop. (probably not much there at all - if anything)
And maybe also add, when you switch to that desktop.
(try avoidking mouse movements or key presses to reduce the log output)
Here is mine when I move it (just some focus change as I click on the title bar):
_focus_change((<ClientWindow object at 0x1ebd500 (xpra+client_window+ClientWindow at 0x1f5e010)>, <GParamBoolean 'has-toplevel-focus'>)) update_focus(4,True) _focused=None _focus_change((<ClientWindow object at 0x1ebd500 (xpra+client_window+ClientWindow at 0x1f5e010)>, <GParamBoolean 'has-toplevel-focus'>)) update_focus(4,False) _focused=4
And this shows up when I switch to the desktop the window is now shown on:
Got map event: <gtk.gdk.Event at 0x1ebe0f8: GDK_MAP> xget_u32_property(<gtk.gdk.Window object at 0x1ebdc30 (GdkWindow at 0x1c78120)>, _NET_WM_DESKTOP)=1 get_workspace() found value=1 from <gtk.gdk.Window object at 0x1ebdc30 (GdkWindow at 0x1c78120)> / _NET_WM_DESKTOP _focus_change(()) update_focus(4,False) _focused=None setting new cursor: xterm=<enum GDK_XTERM of type GdkCursorType> _focus_change((<ClientWindow object at 0x1ebd500 (xpra+client_window+ClientWindow at 0x1f5e010)>, <GParamBoolean 'has-toplevel-focus'>)) update_focus(4,True) _focused=None
Unfortunately, this "job" thing has me completely swamped right now. I likely won't be able to try the patch for a couple days.
Sorry for delay, I see that r2813 was already released in 0.8.7 which I started to test.
Antoine, from your explanation it looks like "unmapped" windows moved to another desktop may be a single cause of all the troubles that I had with applications that "not really" moved to another desktop but only appears as such. Notably I had
With Xpra-0.8.7 windows can be reliably moved between desktops and they are remembering their position on session re-attach. Well done.
Thank you very much for fixing this problem and once again apologies for rant.
I believe this is fixed - feel free to re-open if not.
This is still broken for me.
This is seriously impacting the usability of xpra for me. Could we add an option to disable workspace tracking until we sort this out? (Previously I was inconvenienced once a day, when I first connected. Now I'm having trouble every time I change desktops.)
Sure, I'll see what I can do, but first can you answer the questions in comment:11 about your setup so I can try to reproduce (and then I'm confident this can be fixed one way or another). ie: xinerama or not, driver, etc..
Oops, I missed that request. Sorry about that.
xpyinfo has been attached.
I'm running dual monitors using nVidia's
TwinView technology, not Xinerama. I'm not super versed in the differences, but my understanding is that Twinview handles the multiple displays in the driver, and - for the most part - X just sees a single big display. (I say "for the most part" because X is still aware that there are multiple screens because, for example, KDE can set a separate background image on each monitor.)
Hah, that's very odd, I would have thought that
TwinView would make it easier not harder, since the whole display is one area/one driver.
Can you post your server log message which is going to be similar to this one:
max client resolution is 2560x1600 (from [[2560, 1600]]), current server resolution is 2560x1600
Until I can figure out what is going on here, I may be able to detect multi-monitor/screens setups and disable the preserve feature automatically (at least until I figure out what is going on)
Just a thought, this may not be a "workspace" thing but a "screen" thing, in which case this may be what you need:
--- src/xpra/client_window.py (revision 2827) +++ src/xpra/client_window.py (working copy) @@ -227,7 +227,8 @@ if screen_num and screen_num>=0 and screen_num<display.get_n_screens(): screen = display.get_screen(screen_num) if screen: - self.set_screen(screen) + #self.set_screen(screen) + log.info("***** not setting new window to screen %s", screen_num) self.set_app_paintable(True) self.add_events(WINDOW_EVENT_MASK)
Also worth checking: you did upgrade your server with "xpra upgrade" since the last release? (you can check the version running with "xpra info") Also, I forgot to ask, what is the client OS/version?
The reason why I ask is that popup windows are generally "
Override-redirect" windows, and those would not be affected by the workspace code at all, only the "screen" preserve code, and the screen preserve code should never fire (at least on up-to-date versions) since the window is new and therefore does not have any preferences recorded yet (and in the case of OR windows, it never will).
0.8.7 saved me but only after I upgraded both client and server (followed by
xpra upgrade) so Antoine is correct, it's better to make sure that everything is up-to-date. :)
Updating only client from version 0.8.5 didn't fix all issues for me, but upgrading server as well made the difference.
Here's the server log text:
max client resolution is 3600x1200 (from [[3600, 1200]]), current server resolution is 1680x1050 new resolution matching 3600x1200 : screen now set to 3840x2048
(Last night I was running at home with just the laptop display, hence the smaller current server resolution.)
I'm still running the 0.8.4 client - can't risk a server upgrade for a few more hours. (It's generally no problem, but I really can't afford to have my current runs get interrupted.) I'll upgrade the server later today and test again.
OK. Once I upgraded the server everything looks good.
My apologies for the confusion. From our earlier conversation I thought all the fixes were client side so I didn't worry about the server upgrade.
We can close this again.
Great, thanks for testing.
FYI: I've just added your resolution to the default XDummy xorg.conf we ship: see r2840. Assuming that you do use XDummy and not Xvfb (I still don't know what distro/version you use), this should make things work better with your setup (no menus scrolling off the screen, etc). You can apply it to your current xorg.conf or just wait for the next release.
I am using XDummy. I'm running Ubuntu 12.04 64-bit at the server and Kubuntu 12.04 32-bit at the client.
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/259