Bug 203931

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