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