Xpra: Ticket #773: support more wm states (keep above, below, etc)

As part of the work to better support all the window manager hints, we should try to support more states - and sync them both ways, so that an application can request a window to be kept above others (or below or whatever) and that the user can do the same thing using the client side window manager and we will reflect that on the server side (which should then be taken into account when re-stacking windows, focus, etc)

Somewhat related to #765, #723, etc.


Sat, 03 Jan 2015 06:24:29 GMT - Antoine Martin: owner, status, description changed

Sat, 03 Jan 2015 09:05:10 GMT - Antoine Martin: owner, status changed


+ misc

Those new states can be seen using xpra info.


afarr: this is more FYI than anything else, though a bit more testing on OSX wouldn't hurt. As of r8368, the test application to use is "test window states". Useful client side debug flag: -d window.

Sat, 24 Jan 2015 02:17:28 GMT - alas:

Doing a quick test of the "test window states" buttons... it looks like the windows client is more problematical than the osx.

windows: maximize works, unmaximize doesn't work, fullscreen works, unfullscreen doesn't work, decorate/undecorate works, keep above works, not above works (for the test_window, doesn't trigger fix for firefox window), keep below works for one or two toggles - but then it takes top level focus again, not below doesn't work at all, stick doesn't seem to do anything ( invalid _NET_WM_DESKTOP request: workspace=4294967295, number of desktops=1 maybe it needs a second display to test?), unstick doesn't seem to do anything, skip/not skip taskbar doesn't seem to do anything.

osx: maximize works, unmaximize works, fullscreen works, unfullscreen works, decorate/undecorate work, keep above/ not above work, keep below/ not below work, stick/unstick doesn't work (again 2015-01-23 18:04:15,848 invalid _NET_WM_DESKTOP request: workspace=4294967295, number of desktops=1, will test again with dual monitor setup later), skip pager/not skip pager/skip taskbar/not skip taskbar - no sign of any effects.

Sat, 24 Jan 2015 05:35:16 GMT - Antoine Martin:

OK, thanks for the _NET_WM_DESKTOP info, turns out to be a bug which also uncovered other bugs in this area, fixed in r8537 (will backport). The workspace stuff is only supported on Linux AFAIK, Windows 10 will finally support virtual desktops but I very much doubt that GTK2 will ever support it... which means we will need pywin32 monkey patching to support it.


Wed, 18 Feb 2015 01:35:54 GMT - alas:

Well, it's been a while... and it looks like I neglected to list versions for above comment. So I went through it again.

Win32 0.15.0 r8647 client, fedora20 0.15.0 r8661 server.

(Stopping the session to re-start and try to grab logs, I got the following traceback server-side, while using your beta server build. Might be a coincidence, but I only had two xterms and the test_window_states.py open when shutting down the server with a control-c:

2015-02-17 17:18:08,918 error trying to stop pulseaudio
Traceback (most recent call last):
  File "/usr/lib64/python2.7/site-packages/xpra/server/server_base.py", line 329, in cleanup_pulseaudio
  File "/usr/lib64/python2.7/subprocess.py", line 1551, in terminate
  File "/usr/lib64/python2.7/subprocess.py", line 1546, in send_signal
    os.kill(self.pid, sig)
OSError: [Errno 3] No such process
2015-02-17 17:18:09,431 xpra is terminating.


Summary: fullscreen button seems not to be working with above mentioned versions, and keep below is more like "put below". Not sure what might have happened with fullscreen button, but it sounds like you're saying that the keep below is probably a GTK bug?

Wed, 18 Feb 2015 09:24:12 GMT - Antoine Martin:

fullscreen/unfullscreen no longer do anything

Grrr. Works fine here on XP. Can you try with -d metadata,window. All the changes are metadata updates which now have their own debug flag (in later 0.15 builds)

keep below only seems to work to put the window below..

Did this used to work before with any of our builds? I've tried to debug this and we're not changing its state after calling set_below(True). Maybe win32 doesn't have a keep below state, just a push below action? (so not even a GTK bug, just the best approximation of the API call)

Reconnecting to same server session with new client session, the keep below button is no longer working.

You mean that it doesn't push it below, I think. That would be because it is already "below" as far as the server is concerned - so nothing is updated. Undoing the keep below should "fix" that.

Wed, 18 Feb 2015 09:48:06 GMT - Antoine Martin:

Forgot to mention about the pulseaudio error: it is harmless, r8681 should now skip the scary looking warning.

Wed, 18 Feb 2015 23:23:10 GMT - alas:

Ok, ran it again with same client and server, -d metadata,window.

Started the session (2 xterms). Ran test_window_states.py. Clicked fullscreen. Clicked unfullscreen. Clicked fullscreen. Clicked unfullscreen. Closed session.

Attaching (relatively short) client-side log.

Wed, 18 Feb 2015 23:24:07 GMT - alas: attachment set

Win 32 client, fullscreen & unfullscreen buttons, -d metadata,window

Thu, 19 Feb 2015 02:51:50 GMT - Antoine Martin:

As of r8686, we also forward changes to the "modal" state and handle the corresponding "_NET_WM_STATE" message. Note: we still don't do anything with it client side, but hopefully one day we will. (GTK only supports global modal windows and we want per-application modal windows, see r3708)

Sun, 22 Feb 2015 16:13:48 GMT - Antoine Martin:

I've just tested again with both Windows 7 and Windows XP, and I get the same thing with both, which is the same messages that you are seeing your log above (only -d metadata is needed):

2015-02-22 23:07:28,562 update_metadata({'fullscreen': True})
2015-02-22 23:07:28,566 set_metadata({'fullscreen': True})
2015-02-22 23:07:31,157 update_metadata({'fullscreen': False})
2015-02-22 23:07:31,157 set_metadata({'fullscreen': False})

And with every change, the window goes fullscreen / unfullscreen.. What am I doing wrong? I've uploaded the exact build that I have used for testing: Xpra_Setup_0.15.0-r8689.exe. (I've used the latest trunk for the server)

Tue, 24 Feb 2015 00:17:52 GMT - alas:

I'm not sure who is doing what wrong at this point.

Testing again with Xpra_Setup_0.15.0-r8689 on windows 8.1 against a fedora 20 0.15.0 r8661 server, I managed to confuse myself. A lot.

2015-02-23 15:47:40,811 update_metadata({'fullscreen': True})
2015-02-23 15:47:40,811 set_metadata({'fullscreen': True})

... but when I clicked the unfullscreen button, the window didn't respond and I saw no output from the client.

At this point I can no longer repro the issue, despite being able to do so an hour ago, and despite not having made any change to client or server version (it has been, in fact, the same server session all along).

On a hunch I even tried to uninstall the java-devel for #718... no effect.

I will try again tomorrow... and if I still can't repro, I suppose we'll call it fixed?

Tue, 24 Feb 2015 01:01:31 GMT - Antoine Martin:

... but when I clicked the unfullscreen button, the window didn't respond and I saw no output from the client.

It would be worth capturing xpra info | grep fullscreen at that point, maybe the server thinks that the window is not fullscreen, and so the request to unfullscreen it is simply ignored? Or something.

Unable to unfullscreen, I grabbed the session with another machine, osx... and both buttons worked as expected with it... except that when unfullscreening, the window was still larger than the display and had to be manually resized.

That would be because the application remembers its size before going fullscreen, we don't keep that information anywhere (either client side or server side). It's not very practical but applications are allowed to make windows bigger than the screen! So I don't think we should worry too much about this one, it's a corner case anyway.

Then, perhaps simply to utterly mystify me... both buttons suddenly started working on the right-most monitor as well.


I will try again tomorrow... and if I still can't repro, I suppose we'll call it fixed?

No rush to close this ticket, I think it's mostly done but there may be a race still present. Perhaps similar to #790, making us not update metadata when we should.

Fri, 06 Mar 2015 23:23:09 GMT - alas:

Quick update.

Had Max test again with that now fixed win32 client - everything seemed to work as expected. I'm suspecting that the missing pywin32 from our builds might've been the issue (?).

He did also mention that the osx keep above and keep below don't seem to be working (it looks like they had been previously).

Sun, 08 Mar 2015 06:45:42 GMT - Antoine Martin:

Had Max test again with that now fixed win32 client - everything seemed to work as expected. I'm suspecting that the missing pywin32 from our builds might've been the issue (?).

We show the version of pywin32 we bundle in various places (bug report tool, Version_info.exe). I doubt that you were missing pywin32 completely, as things would not work well without it. Worth checking. The current version is 219.

He did also mention that the osx keep above and keep below don't seem to be working (it looks like they had been previously).

I doubt it, unless we somehow switched to a different GTK version on OSX.

Unless you can confirm that this has regressed from an earlier build, please close this ticket.

Mon, 09 Mar 2015 23:50:29 GMT - alas: status changed; resolution set

Double checking with a new osx client build, Max found keep above and keep below working as expected... so I'm closing this. While I can.

Thu, 19 Mar 2015 15:02:22 GMT - Antoine Martin:

r8802 now syncs more window attributes back with the server (for X11 clients only): we watch for changes to the window's _NET_WM_STATE, which has a lot more useful information than what we get from GTK, and send that back to the server.

Sat, 28 Mar 2015 08:36:23 GMT - Antoine Martin:

Found one more problem related to this change and #790: we end up sending a configure packet with metadata for OR windows.. which is illegal and caused the warnings which made me add debug in r8852 + r8854.

Now, the state updates we sent aren't helpful for an OR window:

{'skip-taskbar': True, 'skip-pager': True}

And maybe we should skip those?

But we may encounter updates that are, so we need to handle this case anyway. r8855 does that.

Sat, 28 Mar 2015 08:37:42 GMT - Antoine Martin: attachment set

the two flags we could skip - but which would then not be synchronized unless we add more code server-side.. (yuk)

Sat, 23 Jan 2021 05:05:32 GMT - migration script:

this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/773