Version: (using KDE 4.3.0) Installed from: Gentoo Packages Autohiding panels show up under windows with the 'keep above others' flag set. In my opinion, the user's wish to show such a hiding panel trumps their wish to keep some nearby window above others - it is the same action as focusing another window with the flag set. I therefore guess this could be solved (for all window managers) if autohiding panels' windows also had this flag set automatically.
hmm, coukd be a kwin issue?
I can reproduce this with KDE 4.4 SVN 1068732 | 4.6.0
*** Bug 217544 has been marked as a duplicate of this bug. ***
yes, i think this is a kwin issue; let's see what the kwin team says. autohide panels are still dock windows; they are just shown/hidden when autohiding is on and that seems to change the stacking order with relation to "always on top" windows.
I would like to see xprop of such an autohidden panel. If the window is really still a dock I cannot think of how it is possible that they are stacked beneath other windows (except fullscreen windows).
keep_above clients are always on top of docks. (the autohiding one is, just checked) - joe user just doesn't see that because of the strut (you have to do alt+lmb drag to get a window crossing a dock) The NETWM spec suggests the to be on the same layer - the final decision might be upon the focus hint/state. Resetting to whishlist, cause due to the vague spec, it's in the cards, but not a bug - i've currently no real opinion on why one's better than the other, maybe autohiding panels should set themselves keep_above and we take that into account for the docks (if it's not anyway) ---- SNIP ------------ - windows of type _NET_WM_TYPE_DESKTOP - windows having state _NET_WM_STATE_BELOW - windows not belonging in any other layer -> windows of type _NET_WM_TYPE_DOCK (unless they have state _NET_WM_TYPE_BELOW) and windows having state _NET_WM_STATE_ABOVE - focused windows having state _NET_WM_STATE_FULLSCREEN
> keep_above clients are always on top of docks. (the autohiding one is, just > checked) - joe user just doesn't see that because of the strut (you have to do > alt+lmb drag to get a window crossing a dock) > > The NETWM spec suggests the to be on the same layer - the final decision might > be upon the focus hint/state. meh, would have said that docks are in an own layer - just reread the section and it makes sense: yakuake should be above a panel. Focus state won't help as docks don't take focus IIRC > > Resetting to whishlist, cause due to the vague spec, it's in the cards, but not > a bug - i've currently no real opinion on why one's better than the other, > maybe autohiding panels should set themselves keep_above and we take that into > account for the docks (if it's not anyway) setting keep_above sounds like a sensible solution and should be easy to check if KWin implements that already through a window rule.
(In reply to comment #7) > Focus state won't help as docks don't take focus IIRC Yes, that's why i assume the window could ultimately win against the dock (focused keep_above clients win over others, but likely only because of the raise one activation thing)
https://git.reviewboard.kde.org/r/104297/
*** Bug 196685 has been marked as a duplicate of this bug. ***
Git commit e2a0ed5c7e4252b71abf18b1cfb1a9a19dbbf73b by Thomas Lübking. Committed on 16/03/2012 at 02:31. Pushed by luebking into branch 'master'. special case keepAbove Docks This can be used by (autohiding) panels to get the panel above other keepAbove windows Since the activation still impact the stacking order, the panel should still use QWidget::raise() or eventually KWindowSystem::raiseWindow(WId win) to (forcefully) get the panel on top. NOTICE: latter is actually a call for tools like pagers and taskbars, don't abuse it but preferably use QWidget::raise() instead. Unless the user doesn't type into the keepAbove window while activating the panel at the same time, this *should* be sufficient. REVIEW: 104279 M +7 -4 kwin/layers.cpp http://commits.kde.org/kde-workspace/e2a0ed5c7e4252b71abf18b1cfb1a9a19dbbf73b