Bug 203924 - a static panel allowing to be overlapped is always placed behind windows
Summary: a static panel allowing to be overlapped is always placed behind windows
Status: RESOLVED INTENTIONAL
Alias: None
Product: plasma4
Classification: Plasma
Component: panel (show other bugs)
Version: unspecified
Platform: Debian testing Linux
: NOR normal
Target Milestone: ---
Assignee: Plasma Bugs List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-08-15 11:36 UTC by Gunter Ohrner
Modified: 2010-05-09 00:59 UTC (History)
3 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 Gunter Ohrner 2009-08-15 11:36:41 UTC
Version:            (using KDE 4.3.0)
OS:                Linux
Installed from:    Debian testing/unstable Packages

I have a small panel in the lower right screen corner, carrying my system tray applet. This panel is static but allows to be overlapped by application windows.

This worked fine in KDE 4.2.x, however in KDE 4.3.0, as soon as the mouse cursor leaves the panel, it automatically places itself under all application windows in this region.

ie. if I move the mouse into the corner where the panel resides, it shows up, but as soon as I move the mouse away it's immediately hidden again by the windows in this area.

That's slightly annoying, as I need to explicitely trigger the panel now to look for eg. status or progress indicators in the systray icons.

Expected behaviour would be that the panel stays visible until I raise one of the windows overlapping it. (ie. I'd expect the panel to behave as a "normal" window regarding window stacking, bringing the panel "window" to front if the mouse cursor triggers it and leaving it there until another window is raised "higher". That's also how KDE 4.2 did it.)
Comment 1 Marco Martin 2009-08-16 21:45:20 UTC
that iirc was explicitly put in, don't remember the reason. i don't use it so i have no idea what is the more expected behaviour, could make sense revert to the old behaviour?
Comment 2 Aaron J. Seigo 2010-05-09 00:59:50 UTC
the only way we could revert it is if we add another hiding style. i'd really, really like to avoid that as the menu is already pretty full. this is the only reported complaint we've had of the new feature, versus numerous requests for the current behaviour.