Bug 203931 - Autohiding panels show up under windows with 'keep above others' set
Summary: Autohiding panels show up under windows with 'keep above others' set
Status: RESOLVED FIXED
Alias: None
Product: kwin
Classification: Plasma
Component: core (show other bugs)
Version: unspecified
Platform: Gentoo Packages Unspecified
: NOR wishlist
Target Milestone: ---
Assignee: KWin default assignee
URL:
Keywords:
: 196685 217544 (view as bug list)
Depends on:
Blocks:
 
Reported: 2009-08-15 12:27 UTC by Miroslav Ľos
Modified: 2012-03-18 21:54 UTC (History)
7 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Miroslav Ľos 2009-08-15 12:27:23 UTC
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.
Comment 1 Marco Martin 2009-08-16 21:39:38 UTC
hmm, coukd be a kwin issue?
Comment 2 Kolia 2010-01-04 12:04:41 UTC
I can reproduce this with KDE 4.4 SVN 1068732 | 4.6.0
Comment 3 Chani 2010-02-01 03:52:04 UTC
*** Bug 217544 has been marked as a duplicate of this bug. ***
Comment 4 Aaron J. Seigo 2010-05-21 04:45:45 UTC
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.
Comment 5 Martin Flöser 2011-07-30 17:39:58 UTC
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).
Comment 6 Thomas Lübking 2011-07-30 19:05:17 UTC
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
Comment 7 Martin Flöser 2011-07-30 19:20:53 UTC
> 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.
Comment 8 Thomas Lübking 2011-07-30 19:28:08 UTC
(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)
Comment 9 Thomas Lübking 2012-03-16 01:42:05 UTC
https://git.reviewboard.kde.org/r/104297/
Comment 10 Thomas Lübking 2012-03-18 14:04:33 UTC
*** Bug 196685 has been marked as a duplicate of this bug. ***
Comment 11 Thomas Lübking 2012-03-18 21:54:52 UTC
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