When a Java Swing application is shaded first and then minimized, Java does not receive a De-iconify event upon un-minimization of the Swing application. The Swing application then fails to render properly when subsequently un-shaded because it does not think it has been de-iconified yet. To demonstrate this, we ran the attached sample code (Iconify.java) which simply outputs the events received by Swing. Reproducible: Always Steps to Reproduce: 1. Compile the attached java Swing application (Iconify.java) 2. Run the application 3. Shade the application 4. Minimize the application 5. Un-minimize the application 6. Un-shade the application Actual Results: The Iconify application outputs the following to standard out: Window Opened Event Window Activated Event Window Deactivated Event Window Iconified Event Window Activated Event Expected Results: The Iconify application should output the following to standard out: Window Opened Event Window Activated Event Window Deactivated Event Window Iconified Event Window Deiconified Event <--- This is the missing event ! Window Activated Event Same thing can be observed when switching desktops. When a Java Swing application is shaded first and a desktop switch is performed, the Swing application receives an Iconification event. But when we switch back to the original desktop, no deiconification event is received.
Created attachment 78203 [details] The sample Iconify java Swing application
with which KWin version have you tested? With which Java version? How does it behave on other window managers, e.g. Compiz or Mutter?
void Client::map(allowed_t) { .... if (!isShade()) { .... exportMappingState(NormalState); } else exportMappingState(IconicState); } altering the shade state does not export the mapping state so everything relying on the clientmessage rather than the WM_STATE will not get the change. @Mike Can you compile a patch? ("because otherwise i'd have to install java...")
Created attachment 78209 [details] Compiled Iconify sample application
Created attachment 78210 [details] Compiled Iconify sample application
Created attachment 78212 [details] Compiled Iconify sample application
Hi there, Thanks for the reply. Forgive my ignorance but I'm not too sure what you meant by patch, but I have attached the compiled java application for you (compiled using JDK 1.6.0_18). Just download the 3 files and run "java Iconify". Please let me know if you meant something else and I will upload it. We have tested this issue with: * KWIN 4.8.5 * KWIN 4.9.5 On KWIN 4.8.5 we tested with and was able to reproduce the issue with: - Java Hotspot VM 1.6.0_20 - Java Hotspot VM 1.7.0_17 - OpenJDK VM 1.7.0_15 On KWIN 4.9.5 we were also able to reproduce the issue. I will need to verify which java version was used. We have tried other window managers with similar shade functionality (ie: openbox) and they did not seem to have the problem. I will get the output of the Iconify Sample program for you on those other window managers.
As a test we ran the Iconify sample application on KWIN 3.0 with Java HotSpot JVM 1.6.0_34 and it does NOT seem to have the issue. The sample application receives the appropriate De-iconify event based on its output. Seems in KWIN 3.0 the Iconified/Deiconified events are received when I shade/unshade the Swing application, as opposed to KWIN 4.8.5 where the Activated/Deactivated events are received when I shade/unshade the Swing application.
I mean like "compile a patched version of kwin" and take your reply as "no". (compiling a java class is just about within my skills ;-) Gonna install OpenJDK and check whether the patch works.
That's good to hear, because patching kwin is well out of my skill level ;-)
Quick addendum to our note above regarding what KWIN versions/Java versions we tested: - We were able to reproduce the issue on KWIN 4.9.5 with Java HotSpot JVM 1.7.0_17 - We also tested the metacity window manager and could not reproduce the issue.
There's a fixing patch in the linked RR - also the current kwin behavior is inconsistent, so there's some bug for sure.
Git commit 607031cb4daec85082d35699214d2f9ae2ab386d by Thomas Lübking. Committed on 19/03/2013 at 22:00. Pushed by luebking into branch 'master'. set / withdraw iconic state for shaded clients Should shaded windows be iconic? I don't know. Apparently nobody does. (google found me discussions but no conclusion) OpenBox, Metacity and Compiz set shaded Windows iconic, Sawfish and IceWM don't. Either way kwin presently sets shaded windows iconic when you map them (client.cpp, void Client::map(allowed_t)) so to remain consistent with ourselves and half of the other WMs i set it. Otherwise it should not be set when unshading a window (no justification but noteworthy: the bug reporter seems to intend to pause expensive painting when the window is iconic and in that regard it's oc better to have it for shaded windows) FIXED-IN: 4.11 REVIEW: 109593 M +2 -0 kwin/client.cpp http://commits.kde.org/kde-workspace/607031cb4daec85082d35699214d2f9ae2ab386d
Thanks Thomas for all your help.
Well, thanks for pointing this issue out. Aside that: bugs only exist to die, so there's no need to be extra thankful for that ;-)