Version: (using KDE KDE 3.1.2) Installed from: Debian testing/unstable Packages OS: Linux I'm trying to take snapshots of various menus from a maximized application, with my focus policy set to follow the cursor, and I've run into this bug. Set the app to be "always on top" so I can get to it, then take the snapshot, and after having done so, it's no longer "always on top" and I have to go dig it out. Presumably you need to toggle that off in order to get it out of the way of the screenshot, but I think you should track its status and toggle it back on if you had to turn it off. This is on the borderline between a bug and a wishlist, and not exactly high priority, but I think it's a bug because the app should do what I tell it to do.
This is more of a general problem, not ksnapshot specific.
*** Bug 67636 has been marked as a duplicate of this bug. ***
*** Bug 75779 has been marked as a duplicate of this bug. ***
#75779 has the same technical problem, affecting placement when restoring trayed app.
*** Bug 100794 has been marked as a duplicate of this bug. ***
*** Bug 103408 has been marked as a duplicate of this bug. ***
*** Bug 107844 has been marked as a duplicate of this bug. ***
I reproduced this bug by selecting "keep above others" instead of "always on top" as I think this replaces it in 3.5.4 I can reproduce the behavior for ksnapshot in kde 3.5.4 (Gentoo Packages). However, the following bugs marked as duplicate, I cannot reproduce: bug # 67636 -- Fullscreen forgets "Always on top" bug # 75779 -- Xinerama - KWin runs window placement code on windows that have been visible once already bug # 100794 still occurs bug # 103408 still occurs bug # 107844 I cannot test since I do not run GNOME
*** Bug 154327 has been marked as a duplicate of this bug. ***
Although this is a valid problem I do not see it as a KWin bug; rather it is a general window management feature request. The ICCCM specifications state in section 4.1.3.1 "WM_STATE Property" [1]: "Once the top-level window has been withdrawn, the client may re-use it for another purpose." To me this means that when a window is withdrawn there is no guarantee that the window will be the "same" one when it exits the withdrawn state, therefore remembering states for such windows would be wrong. The removal of current states on window withdrawal is even stated in the EWMH specifications under the "_NET_WM_STATE" section [2]: "The Window Manager should remove the property whenever a window is withdrawn..." Currently the only "state" that is remembered for withdrawn windows is _NET_WM_WINDOW_OPACITY, however as that property is not officially in the EWMH its behaviour is undefined. Before this problem can be fixed we are required to discuss, modify and extend the existing EWMH specifications to include window minimisation as the old ICCCM way does not take into account modern compositing techniques or system tray minimisation (Although it could be argued that it is abusing the system tray and shouldn't be done to begin with). [1] http://tronche.com/gui/x/icccm/sec-4.html#s-4.1.3.1 [2] http://standards.freedesktop.org/wm-spec/wm-spec-latest.html#id2551694
given comment #10 this feature request cannot be implemented without violating the NETWM specification. So I am sorry that I have to set the request to WONTFIX but want to thank you for the request.
As a notice for the particular issue: it does make sense to force ksnapshot to stay on top by a window rule, what resolves this very issue. NETWM spec will unlikely be changed in this regard.