Bug 317025

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