Bug 337060 - Desktop toolbox can visually conflict with (e.g. overlap) containment contents
Summary: Desktop toolbox can visually conflict with (e.g. overlap) containment contents
Status: RESOLVED FIXED
Alias: None
Product: plasmashell
Classification: Plasma
Component: general (show other bugs)
Version: master
Platform: unspecified Linux
: NOR normal
Target Milestone: 1.0
Assignee: Sebastian Kügler
URL:
Keywords:
: 336733 340303 (view as bug list)
Depends on:
Blocks:
 
Reported: 2014-07-04 13:53 UTC by Harald Sitter
Modified: 2021-03-10 04:18 UTC (History)
13 users (show)

See Also:
Latest Commit:
Version Fixed In:
bhush94: Usability+
bhush94: VisualDesign+


Attachments
screenshot (769.20 KB, image/png)
2014-07-04 13:54 UTC, Harald Sitter
Details
weird icon placement (116.18 KB, image/jpeg)
2014-10-27 22:08 UTC, Andreas Sturmlechner
Details
overlap still present (108.02 KB, image/png)
2017-03-05 09:06 UTC, Rik Mills
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Harald Sitter 2014-07-04 13:53:52 UTC
the plasma toolbox in the top-left corner partially overlaps with the folder item in the top-left corner.

this looks weird and decreases the clickable area available for the folder item.

additionally this actually gives incorrect visual hinting as hovering over the folder item will (apparently) draw the highlight rectangle ontop of the toolbox making it appear as though clicking in the top left corner of the item will launch the item rather than access the toolbox, while in fact it does trigger the toolbox and not the item itself

Reproducible: Always
Comment 1 Harald Sitter 2014-07-04 13:54:26 UTC
Created attachment 87544 [details]
screenshot
Comment 2 David Edmundson 2014-07-04 15:36:48 UTC
Maybe another reason to move the toolbox top right.
Comment 3 Eike Hein 2014-07-04 16:19:26 UTC
Problem survey:

1) Overlap: It overlaps. This is identical to KDE 4 behavior, the difference being that KDE 4 defaults to putting the toolbox into the top-right corner while plasmashell puts it in the top-left. This isn't really Folder-specific, it's a broader conceptual problem of the toolbox UI possibly conflicting with containments that's never been really addressed.

In the KDE 4 Homerun containment what we do is hide the toolbox by default and have a toggle action in the Homerun menu to unhide it, but I'm not sure that's desirable for a bundled default containment (or where to put the toggle action).

2) z order: I can't reproduce that part, and it's not visible on the screenshot attachment. The containment's rendering below the toolbox (and the toolbox, being on top, is the interactive element), as expected.

Options / notes:

- Folder could (perhaps, haven't checked API) push icons out of the way of the toolbox, but that would result in a wide margin. I don't think this is what users want ... they're more likely to move the toolbox to the opposite corner again to avoid the conflict in the first place.

- Moving the toolbox on containment switch isn't practical because it means meddling with user config (or trying to distinguish user-desired config from defaults, which is one of those magic tri-state ideas that ends up being trouble).

- plasmashell could change the default to top-right again, therefore adding Marco to CC here to consider it.

- Distros that want to default to Folder could use the scripting API to put the toolbox in an appropriate location since they have one more bit of information vs. plasmashell (namely the deviating default).
Comment 4 Marco Martin 2014-07-07 08:30:45 UTC
another option, there could be an extra added margin to availableScreenRect, so they don't overlap
Comment 5 Eike Hein 2014-07-07 11:36:01 UTC
That would make things easier on containment code, but I'm not sure it's right, depending on how it was implemented - IIRC containments can technically provide their own toolbox items, so they'd need to have control over how they factor into availableScreenRect. Besides though, this would be the same results-wise as Folder pushing things aside, and I still think users don't actually want that extra margin.
Comment 6 Marco Martin 2014-07-07 11:44:02 UTC
"IIRC containments can technically provide their own toolbox items"
not really, what toolbox item gets created is decided solely by the shell package
Comment 7 Bhushan Shah 2014-10-03 09:04:28 UTC
*** Bug 336733 has been marked as a duplicate of this bug. ***
Comment 8 Bhushan Shah 2014-10-24 14:53:52 UTC
*** Bug 340303 has been marked as a duplicate of this bug. ***
Comment 9 Andreas Sturmlechner 2014-10-27 22:08:50 UTC
Created attachment 89342 [details]
weird icon placement

Thankfully I have found this bug, or else I would have been forced to open another one about 'the button formerly known as The Cashew' ;)

Anyway, it feels like my problem with it does not warrant its own bug, so I'll be attaching a screenshot underlining another oddity with it. The way I like my plasma, there is a hidden task manager panel in the middle on the left. Bewildering, then, to watch how the desktop toolbox icon moves as I increase the width of said panel, and remain there when I set that panel to auto-hide. I don't think the old cashew ever behaved like that when you did something similar to the right.
Comment 10 Andreas Sturmlechner 2014-10-27 22:19:36 UTC
Out of fun, I just created a setup with four panels to all sides. The icon will always get in the way in that case - all for duplicating right-click content? ;)
Comment 11 Bhushan Shah 2014-10-29 06:50:55 UTC
What do usability and VDG guys say about this?
Comment 12 ken taylor 2014-10-29 08:03:17 UTC
A thread has been started on the VDG forum to ask whether they have any input:

https://forum.kde.org/viewtopic.php?f=285&t=123462&p=322878#p322878
Comment 13 Andrew Lake 2014-12-29 17:24:01 UTC
No reason to not confirm this. It's clearly a problem. We'll provide some VDG feedback shortly.
Comment 14 Andrew Lake 2014-12-31 17:43:40 UTC
So the VDG feedback in order of preference (without consideration about implementation ease) is:

1. Only show the desktop toolbox when there are no panels. This requires making sure the "Desktop Settings" action is available by other means beyond just the right click.
2. De-conflict plasmoid overlaps with the toolbox the same way we de-conflict overlaps between plasmoids - move/resize the plasmoid to prevent the overlap.
3. Move the toolbox to the right.

You can see the thread linked in comment 12 for the discussion.
Comment 15 Kai Uwe Broulik 2017-01-01 21:14:04 UTC
*** Bug 374292 has been marked as a duplicate of this bug. ***
Comment 16 Rik Mills 2017-03-05 09:06:05 UTC
Created attachment 104375 [details]
overlap still present

3 years after the initial reporting of this, it still seems to be an issue in folderview desktop.

This is now exposed quite visibly to a new user or install with the recent switch to folderview as the default desktop containment.

See attached screenshot of latest plasma in Neon dev-unstable.

For what it is worth, I favour a switch of the toolbox to top right, which regardless of any other issue I feel is long overdue.
Comment 17 Eike Hein 2017-03-06 20:37:53 UTC
Patch under review https://phabricator.kde.org/D4956
Comment 18 Rik Mills 2017-03-07 00:05:25 UTC
(In reply to Eike Hein from comment #17)
> Patch under review https://phabricator.kde.org/D4956

Works with broulik's panel/toolbox/icon setup as shown in video in that phab review, but does not work in the default plasma arrangement; i.e. panel at bottom, toolbox top left, and Home and Wastebin items in default places.
Comment 19 Kai Uwe Broulik 2017-03-07 12:44:15 UTC
Git commit d1e81740d37289ac62dce56ceac860f6fd302718 by Kai Uwe Broulik.
Committed on 07/03/2017 at 12:43.
Pushed by broulik into branch 'master'.

[Folder View] Lower toolbox when an item is hovered

Otherwise it might interfere with the item's interaction (e.g. it would overlap the selection button in the top left).

Differential Revision: https://phabricator.kde.org/D4956

M  +11   -0    containments/desktop/package/contents/ui/FolderView.qml

https://commits.kde.org/plasma-desktop/d1e81740d37289ac62dce56ceac860f6fd302718
Comment 20 Rik Mills 2017-03-07 14:47:55 UTC
(In reply to Kai Uwe Broulik from comment #19)
> Git commit d1e81740d37289ac62dce56ceac860f6fd302718 by Kai Uwe Broulik.
> Committed on 07/03/2017 at 12:43.
> Pushed by broulik into branch 'master'.
> 
> [Folder View] Lower toolbox when an item is hovered

Using build: 

http://build.neon.kde.org/job/xenial_unstable_plasma_plasma-desktop/281/

including above change.

Seems to not have had the intended result.

https://www.youtube.com/watch?v=2Xlf2nMO1yc

Tested with a brand new user to make sure all configs and desktop were default.
Comment 21 Nate Graham 2021-03-10 04:18:25 UTC
The Desktop Toolbox is no more. :)