support more wm states (keep above, below, etc)

[Antoine Martin]

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.

Links:

• ​emwh STACKINGORDER
• ​_NET_WM_STATE

[Antoine Martin]

Added:

• "above", "below" and "sticky in r8356
• "skip-taskbar" and "skip-pager" in r8358

+ misc

Those new states can be seen using xpra info.

Caveats:

• support for those flags varies from OS to OS, and some window managers may implement those differently (ie: we need r8359 to fix window positioning after re-enabling window decorations on win32)
• "skip-taskbar" only worked one-way when I tested it (cannot be disabled afterwards) - and it didn't work at all on win32 (though it may work if the flag is set before the window is first shown?)
• we don't necessarily get notified when the action is taken client-side (so things end up out of sync with the server out of date), for example with openbox I never got the above/below window state changes

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.

[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.

[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.

Anyway:

• win32:
  • maximize works, unmaximize doesn't work: what do you mean? Does it stay maximized? I can unmaximize the window whether I maximized it via the button or via the window's top bar buttons.
  • fullscreen works, unfullscreen doesn't work: same question
  • decorate/undecorate works: good, quite a bit of effort went into making undecorated + maximize work on win32 (as GTK breaks it by default)
  • keep above works, not above works (for the test_window, doesn't trigger fix for firefox window): I don't understand this, why would this affect the firefox window in any way? (I assume the firefox window is another xpra forwarded 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: I don't think this works on win32 (GTK bug)
  • unstick doesn't seem to do anything: that's only relevant to multiple desktops (it keeps the window visible on all virtual desktops), and since win32 doesn't have any... it doesn't do anything.
  • skip/not skip taskbar doesn't seem to do anything: looks like a GTK bug, doesn't do anything on X11 either - meh, not sure it is worth the effort for this release (found a link which includes a workaround using pywin32: ​hide window from MS windows taskbar)

• osx:
  • ... works!
  • stick/unstick doesn't work: someone would need to implement workspace support for OSX Lion and later (see ​OS X Mountain Lion: Work in multiple spaces)
  • skip pager/not skip pager/skip taskbar/not skip taskbar - no sign of any effects: probably the same as above, either a bug in GTK or just not implemented on OSX..

[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.

• maximize/unmaximize works as expected.
• fullscreen/unfullscreen no longer do anything (fullscreen button doesn't respond, so hard to really test unfullscreen properly, but it doesn't unmaximize after either using the maximize button or after using the maximize icon in top right of test_window_state window... unlike maximize, there's also no output with a -d window flag).
• decorate/undecorate still work wonderfully.
• keep above/not above work as expected.
• keep below only seems to work to put the window below... after clicking on a couple of other overlapping windows then back to the test_window_states window, it jumps above when taking focus. (As an additional side note, after a few tries through, the keep below button stopped even placing the window below overlapping windows.

(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
    self.pulseaudio_proc.terminate()
  File "/usr/lib64/python2.7/subprocess.py", line 1551, in terminate
    self.send_signal(signal.SIGTERM)
  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.

)

• Tested again with -d window, attaching quick log from client-side, firing test_window_state.py from one of two xterms, move to overlap two local windows- a cmd window and a chrome window, click on keep below, click on one of the overlapping windows, click on the other overlapping window, then click on test_window_state window again... it takes top focus... and I end the session to grab the log. Which doesn't seem to show anything interesting.

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

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?

[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.

[Antoine Martin]

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

[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.

[alas]

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

[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)

[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)

[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.

• At first, when I clicked the fullscreen button, the test_window_states.py window opens to fullscreen and outputs as expected:

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.

• 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.

• A few iterations through this routine, I noticed that, if I put the test_window_states.py window on the left-most monitor (a nearly totally dysfunctional display used only for testing multi-display issues), then both fullscreen and unfullscreen worked as expected.

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

---

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?

[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.

[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).

[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.

[alas]

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.

[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.

[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.

[Antoine Martin]

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

[migration script]

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