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
WM_HINTS
(icon_pixmap + icon_mask or icon_window..)
WM_COMMAND
why not, just forward it
shows what colormap windows are using
I think we can forget about the colormap stuff, I cannot find a single application that doesn't use 24 or 32 bit colormaps!
_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..
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:
Testing with windows7 0.15.0 r8647 v. fedora20 0.15.0 r8601.
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'
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.
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...
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:
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:
Oops, control-z also makes that test window's "red-X" non responsive...
See above, this is expected: that's what "control-z" does.
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.
Done!
See also: ticket:809#comment:12
(ticket is easier to find if we spell EWMH correctly!)
For _NET_FRAME_EXTENTS
and _NET_REQUEST_FRAME_EXTENTS
see #919 and #885.
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/775