Bug 382872

Summary:	Don't let desktop widgets/plasmoids overlap desktop icons
Product:	[Plasma] plasmashell	Reporter:	Gregor Mi <codestruct>
Component:	Containment	Assignee:	Sebastian Kügler <sebas>
Status:	RESOLVED INTENTIONAL
Severity:	wishlist	CC:	nate, plasma-bugs-null, simonandric5
Priority:	NOR
Version First Reported In:	5.9.4
Target Milestone:	1.0
Platform:	Other
OS:	Linux
Latest Commit:		Version Fixed/Implemented In:
Sentry Crash Report:

Description Gregor Mi 2017-07-28 21:23:50 UTC

Situation:
----------
1) Have a laptop and a desktop with some icons and widgets neatly arranged.
2) Switch from external monitor (disconnect) to smaller internal display.
=> The desktop icon's positions change to some random order and the widgets are now on top of some icons so that these icons cannot be seen properly. This is impractical (and looks somewhat untidy).

Suggestion:
-----------
Don't let widgets/plasmoids be placed over desktop icons: the area below widgets could be a "no-go" area for icons. E.g. if widgets are moved around towards icons then these icons automatically move away when or just before they are "hit".

Comment 1 Christoph Feck 2017-08-02 11:58:31 UTC

I doubt this is fixable. Rather, it could remember positions per screen resolution, so that changing resolutions does not cause the random changes.

Comment 2 Gregor Mi 2017-08-03 12:07:20 UTC

Thanks for your assessment. Remembering positions per screen resolution sounds like a good idea.

Meanwhile, I tried to create a Plasma panel on the right side of the screen that
- should be below all windows
- contains the mentioned applets (mostly system monitoring)
- BUT does not appear when the mouse touches the right screen edge, because then using scrollbars with the mouse in fullscreen windows becomes difficult.

In the Visibility settings of the Panel there are four mutual exclusive options "Always Visible", "Auto Hide", "Window Can Cover" and "Windows Go Below".

None of them seem to be suitable because "Window Can Cover" also includes the screenedge triggering of the panel.

Comment 3 Nate Graham 2020-01-22 18:51:49 UTC

I think Christoph is right. The request here describes a potentially undesirable workaround for the actual problem. Let's just fix the actual problem. :)