more complete EWMH specification support

[Antoine Martin]

The specs:

• ​Extended Window Manager Hints
• ​Inter-Client Communication Conventions Manual

Related to #773, #774, #765, etc..

We should also support:

• _NET_CLOSE_WINDOW
• _NET_WM_ALLOWED_ACTIONS - and have some way of figuring out which actions make sense for which clients.. since things like "sticky" may not be applicable to most OSX / win32 desktops, same for "skip-pager" and probably others - when multiple clients are connected (#41), we probably just have to hope for the best and choose the superset of actions
• _NET_MOVERESIZE_WINDOW: already done in r8277
• _NET_WM_MOVERESIZE for osx and win32: #722
• _NET_RESTACK_WINDOW: low priority (only for pagers)
• _NET_WM_STRUT and _NET_WM_STRUT_PARTIAL: code exists but the data is not forwarded to the client
• _NET_WM_HANDLED_ICONS - not sure how to deal with this one..
• _NET_FRAME_EXTENTS and _NET_REQUEST_FRAME_EXTENTS: hard to support multiple clients... (just choose one as master?)
• _NET_WM_OPAQUE_REGION: probably not
• _NET_WM_BYPASS_COMPOSITOR could be used as a hint to the encoders that we expect fast refreshes?
• _NET_WM_PING: we would need to ensure that the client side then sends us a _NET_CLOSE_WINDOW so that we can forward it to the right process, otherwise it might end up killing the xpra client process
• _NET_WM_SYNC_REQUEST: #723
• _NET_WM_FULLSCREEN_MONITORS: meh
• colormaps stuff: could be used as hint to the encoders that we don't need the full colorspace - assuming that there are applications that use this antiquated logic
• window icons specified using WM_HINTS (icon_pixmap + icon_mask or icon_window..)
• WM_COMMAND why not, just forward it

[Antoine Martin]

• _NET_CLOSE_WINDOW done in r8364
• WM_COMMAND forwarded to X11 clients in r8365

[Antoine Martin]

shows what colormap windows are using

[Antoine Martin]

I think we can forget about the colormap stuff, I cannot find a single application that doesn't use 24 or 32 bit colormaps!

[Antoine Martin]

• _NET_WM_BYPASS_COMPOSITOR added in r8551 - only relevant for X11 clients
• _NET_WM_STRUT_PARTIAL / _NET_WM_STRUT in r8552 + r8553 (and found a bug along the way which should be backported: we should not zero pad the length of "strut" data, and we should not error if the length is 4 ints..)
• _NET_SHOWING_DESKTOP in r8554 (win32 and X11 only, not done for OSX)
• _NET_WM_FULLSCREEN_MONITORS in r8554 (we may also want to validate the list of monitors supplied in the client application message, also untested as I only have one monitor attached right now... found a good test case for it though: ​https://bugzilla-attachments.gnome.org/attachment.cgi?id=122703)
• _NET_WM_STATE_SHADED and more actions added to _NET_WM_ALLOWED_ACTIONS in r8556. Note: we don't synchronize back from the client because GTK does not expose the "shaded" state to us..

[Antoine Martin]

These attributes will not be handled:

• _NET_WM_HANDLED_ICONS
• _NET_WM_OPAQUE_REGION

The remaining issues are being moved to #794, so that we can schedule it for a later milestone.
Testing for this ticket largely overlaps with #773.

afarr: there are some new test classes which can be used to test the support for those protocols:

• "test show desktop": should hide all the windows and show the desktop (X11 and win32)
• "test window strut": should reserve 100 pixels on the right hand side of the screen, maximized windows should not cover that area (X11 only)
• "test window states": "shaded" support has been added (X11 only), there's also a new text box allowing you to enter the "fullscreen monitors" (X11 only for now), please refer to the spec for details of what the values mean and what they are meant to do

[alas]

Testing with windows7 0.15.0 r8647 v. fedora20 0.15.0 r8601.

• "test show desktop" works like a champ, though I'm seeing the following output client side (maybe means something):

  2015-02-12 16:27:58,022 failed to set group leader: 'module' object has no attri
  bute 'SHGetPropertyStoreForWindow'
  2015-02-12 16:27:58,032 failed to set group leader: 'module' object has no attri
  bute 'SHGetPropertyStoreForWindow'
  2015-02-12 16:27:59,039 using audio codec: MPEG 1 Audio, Layer 3 (MP3)
  2015-02-12 16:30:33,138 failed to set group leader: 'module' object has no attri
  bute 'SHGetPropertyStoreForWindow'
  

• "test window strut" does indeed reserve about 100 pixels on right hand of screen (coverable with maximize, even of xterms ... but it is win32, will test that again with a linux distro client soon-ish). Oddly though, when I close with the "red-X" the process doesn't close in the xterm from whence it was launched. When I use a "control-z" to stop, the process stops in the xterm, but the strut still displays on the right... after which launching again from same xterm launches a second strut. Trying to close that (after moving to confirm there were two) with a "control-c" produced the following traceback (though it did successfully close that top strut):

  Traceback (most recent call last):
  File "test_window_strut.py", line 23, in <module>
    main()
  File "test_window_strut.py", line 19, in main
    gtk.main()
  KeyboardInterrupt
  

(Possibly related to traceback listed in #807?)

... at which point, further "control-c"s have no effect (just display as ^{C), and "control-z"s don't seem to work at all... and the "red-X" also fails to rid the desktop of the strut.}

• "test_window_states" is throwing out some odd output in the xterm from whence it was launched, but it just seems to be a window_state(<gtk.Window obect at ... flags: with values such as ['maximized', 'fullscreen'] or fullscreen? set of verbose output (expected, I assume).

I notice stick sets a flag saying ['sticky', 'fullscreen'], and unstick makes the flag revert to fullscreen? ... though the test_window_state window is not fullscreen at the time (though, it is also not maximized...)

Oops, control-z also makes that test window's "red-X" non responsive...

[Antoine Martin]

failed to set group leader: 'module' object has no attribute 'SHGetPropertyStoreForWindow'

That's odd, and not directly related to this ticket: this the new code for #799.
r8655 will now log the propsys module we try to use. It should look like this with -d win32 (shown here for windows 7 64-bit):

win32 hooks: propsys=<module 'win32com.propsys.propsys' from 'C:\Program Files (x86)\Xpra\win32com.propsys.propsys.pyd'>

I've just tried it again with the latest beta build on a clean windows 7 VM and I cannot reproduce this error.

@afarr: Can you? With my latest beta builds? If so, please reopen #799.

---

"test window strut" does indeed reserve about 100 pixels on right hand of screen (coverable with maximize, even of xterms ... but it is win32, will test that again with a linux distro client soon-ish)

See comment:4 where it says: (X11 only).
Teaching win32 about reserving space is just too much work right now, maybe in a future version.

I'm not even sure it is possible to emulate what X11 window managers do:

• ​You can't globally reserve screen space; you can put up signs, but if somebody ignores the sign you'll have to decide how to respond
• ​Reserving Desktop Space so maximized windows don't cover it
• ​Using Application Desktop Toolbars - this looks like what we want.. except we don't want to place anything there at all, just reserve the space

We could do it more easily for all of our own windows, since we already have max-size overrides and such, but that's not enough.

---

Oddly though, when I close with the "red-X" the process doesn't close in the xterm from whence it was launched.

with "test window states" ?
Are you sure you didn't "control-z" it first?

When I use a "control-z" to stop, the process stops in the xterm, but the strut still displays on the right... after which launching again from same xterm launches a second strut. Trying to close that (after moving to confirm there were two) with a "control-c" produced the following traceback (though it did successfully close that top strut):
(..)

KeyboardInterrupt is "control-c", which is expected.

"control-z" doesn't kill the process, just "stops" it, and you can resume it with "fg" for foreground or "bg" for background.
Until you do so, it will not respond to any events.

... at which point, further "control-c"s have no effect (just display as C), and "control-z"s don't seem to work at all... and the "red-X" also fails to rid the desktop of the strut.

"control-c" can only affect an application that is running, not one that is already stopped or backgrounded.

"test_window_states" is throwing out some odd output in the xterm from whence it was launched, but it just seems to be a window_state(<gtk.Window obect at ... flags: with values such as ['maximized', 'fullscreen'] or fullscreen? set of verbose output (expected, I assume).

Yes, that shows us what GTK is seeing on the server side, which "should" match what is happening client side. But:

I notice stick sets a flag saying ['sticky', 'fullscreen'], and unstick makes the flag revert to fullscreen?

Two things here:

• there was a bug with the fullscreen state not being synchronized properly: fixed in r8657 (backported in r8659 since I had also backported this bug..)
• stick / unstick should not touch the fullscreen flag at all, so maybe it was already set previously? (and AFAIK, it doesn't do anything on win32)

Oops, control-z also makes that test window's "red-X" non responsive...

See above, this is expected: that's what "control-z" does.

[alas]

Testing with windows 8.1 0.15.0 r8689 client, the propsys are outputting as now expected.

It also looks like I did, indeed, control-z the processes before trying to control-c... oops.

I don't see anything else needing handling here... passing this one back to you to close.

[Antoine Martin]

Done!

[Antoine Martin]

See also: ticket:809#comment:12

[Antoine Martin]

(ticket is easier to find if we spell EWMH correctly!)

[Antoine Martin]

For _NET_FRAME_EXTENTS and _NET_REQUEST_FRAME_EXTENTS see #919 and #885.