This causes problems with applications that need to know the correct state of the window, ie: the test code from #718
Also related to #765, the "iconic" state handling is messy, conflates too many things and then we have the duplication in the desktop manager too.
More info in 718#comment:7: looks like we may have to unmap the window.
unmaps windows to hide them, and re-maps them when shown again
Despite the changes in the patch above to unmap the window when we iconify it, we don't get a Java java.awt.event.WindowEvent[WINDOW_STATE_CHANGED,opposite=null,oldState=0,newState=1]
and from then on, the window state stays as "normal".
This is normally generated in handleIconify
which is fired from handlePropertyNotify
.
Verbose Java logging shows this when we do detect the iconified window:
sun.awt.X11.XFramePeer handlePropertyNotify FINER: Property change XPropertyEvent = type = PropertyNotify, serial = 420, send_event = false, \ display = 140580387884144, window = sun.awt.X11.XFramePeer@f5c5bba(2a00018), atom = WM_STATE:331, time = 242438341, state = 0, sun.awt.X11.XWM isStateChange FINER: Window WM_STATE is 3 sun.awt.X11.XNETProtocol doStateProtocol FINER: doStateProtocol() returns true sun.awt.X11.XFramePeer handlePropertyNotify FINER: Iconified
With xpra:
sun.awt.X11.XFramePeer handlePropertyNotify FINER: Property change XPropertyEvent = type = PropertyNotify, serial = 445, send_event = false, \ display = 140379128433632, window = sun.awt.X11.XFramePeer@471f4073(800007), atom = WM_STATE:293, time = 242882557, state = 0, sun.awt.X11.XWM isStateChange FINER: Window WM_STATE is 872457728 sun.awt.X11.XNETProtocol doStateProtocol FINER: doStateProtocol() returns true sun.awt.X11.XFramePeer handlePropertyNotify FINER: State is the same: 0
Why is the WM_STATE
so out of range?
When I look at it using xprop, it looks fine - same value in both cases... well, it would be because the type of the property is wrong - and it has been wrong.. forever!
r8318 fixes that and should be backported.
r8319 merges the map / unmap patch (with some renaming), it looks safe but could still cause some regressions..
Backport of r8318 in r8320. I probably won't backport r8319.
One more iconification race fixed in r8352 + backport in r8353.
Working as expected. Closing.
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/726