Xpra: Ticket #775: more complete EWMH specification support

The specs:

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

We should also support:



Sat, 03 Jan 2015 12:42:01 GMT - Antoine Martin: owner, status changed


Fri, 16 Jan 2015 11:56:13 GMT - Antoine Martin: attachment set

shows what colormap windows are using


Fri, 16 Jan 2015 11:56:53 GMT - 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!


Mon, 26 Jan 2015 13:31:01 GMT - Antoine Martin:


Tue, 27 Jan 2015 05:39:34 GMT - Antoine Martin: owner, status changed

These attributes will not be handled:

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:


Fri, 13 Feb 2015 01:16:49 GMT - alas:

Testing with windows7 0.15.0 r8647 v. fedora20 0.15.0 r8601.

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

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


Fri, 13 Feb 2015 04:14:14 GMT - 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:

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.


Tue, 24 Feb 2015 00:23:50 GMT - alas: owner changed

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.


Tue, 24 Feb 2015 01:01:58 GMT - Antoine Martin: status changed; resolution set

Done!


Wed, 15 Apr 2015 08:44:18 GMT - Antoine Martin:

See also: ticket:809#comment:12


Sun, 31 May 2015 08:03:51 GMT - Antoine Martin: summary changed

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


Fri, 17 Jul 2015 03:33:33 GMT - Antoine Martin:

For _NET_FRAME_EXTENTS and _NET_REQUEST_FRAME_EXTENTS see #919 and #885.


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

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