Bug 203924

Summary:	a static panel allowing to be overlapped is always placed behind windows
Product:	[Unmaintained] plasma4	Reporter:	Gunter Ohrner <kdebugs>
Component:	panel	Assignee:	Plasma Bugs List <plasma-bugs>
Status:	RESOLVED INTENTIONAL
Severity:	normal	CC:	aseigo, asraniel, notmart
Priority:	NOR
Version:	unspecified
Target Milestone:	---
Platform:	Debian testing
OS:	Linux
Latest Commit:		Version Fixed In:
Sentry Crash Report:

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.