#775 closed enhancement (fixed)
more complete EWMH specification support
Reported by: | Antoine Martin | Owned by: | Antoine Martin |
---|---|---|---|
Priority: | major | Milestone: | 0.15 |
Component: | core | Version: | trunk |
Keywords: | Cc: |
Description
The specs:
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
Attachments (1)
Change History (12)
comment:1 Changed 5 years ago by
Owner: | changed from Antoine Martin to Antoine Martin |
---|---|
Status: | new → assigned |
comment:2 Changed 5 years ago by
I think we can forget about the colormap stuff, I cannot find a single application that doesn't use 24 or 32 bit colormaps!
comment:3 Changed 5 years ago by
_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..
comment:4 Changed 5 years ago by
Owner: | changed from Antoine Martin to alas |
---|---|
Status: | assigned → new |
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
comment:5 Changed 5 years ago by
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...
comment:6 Changed 5 years ago by
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.
comment:7 Changed 5 years ago by
Owner: | changed from alas to Antoine Martin |
---|
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.
comment:10 Changed 5 years ago by
Summary: | more complete emwh specification support → more complete EWMH specification support |
---|
(ticket is easier to find if we spell EWMH correctly!)
_NET_CLOSE_WINDOW
done in r8364WM_COMMAND
forwarded to X11 clients in r8365