Bug 446031

Summary: Improve usability of dragging launchers from Kickoff and Task Manager to desktop
Product: [Plasma] plasmashell Reporter: Jan Rathmann <jan.rathmann>
Component: Desktop ContainmentAssignee: David Edmundson <kde>
Status: ASSIGNED ---    
Severity: wishlist CC: mikel5764, nate, notmart, plasma-bugs
Priority: NOR Keywords: usability
Version: 5.23.3   
Target Milestone: 1.0   
Platform: Other   
OS: Linux   
See Also: https://bugs.kde.org/show_bug.cgi?id=389600
https://bugs.kde.org/show_bug.cgi?id=390817
Latest Commit: Version Fixed In:
Sentry Crash Report:

Description Jan Rathmann 2021-11-24 13:04:09 UTC
I somehow got inspired by one of Nate's recent posts about topics like how intuitive/friendly KDE's UI feels to new users to do a bit of usability testing myself. What I did was pretending that I'm new to KDE and taking a look how easy it is to add icons to the desktop (I don't have desktop icons in my personal setup, so I rarely used this feature before on KDE).

I particulary tested what happens when I just drag a launcher icon from Kickoff to the desktop to create a launcher there. (To me dragging seems to be the most intuitive thing to try first.)

It seems to me that the current user experience is less than optimal and in particular confusing regarding some aspects:

If I drag a launcher icon to the desktop and release the mouse button, the menu that appears offers me three(!) possible ways to add it to the desktop:

1. Copy here
2. Link here
3. (Widgets) Add icon

Each of these three possibilities comes with its own "quirks":

1. == Copy here ==
    a) The desktop icon initially has an exclamation mark added, which makes it look like something is wrong with it. On the first attempt to launch the app you're getting asked if you really want to do this and you trust the applicaton. After that the exclamation mark on the icon goes away and on further launches you don't get asked again. The reason for this is that the copied desktop file is initially not marked as executable.
    b) If something changes to the original desktop file (from /usr/share/applications, e.g. the app updates its icon in any way), these changes don't get applied to the copy of the icon on the desktop. This may not be the desired behaviour, since it means that you must update your copied desktop icons manually (copying them again).
2. == Link here ==
    a) A chain-like symbol is added to the icon indicating that it is representing a symbolic link. This clutters the appearance of the icon a bit IMHO.
3. == (Widgets) Add icon ==
    a) The resulting icon doesn't respect mouse behaviour preferences: It always launches the app via single click, even if one has chosen to launch/open files by double click.
    b) It's harder to move the icon: To do this you have to right click on it and select "Enter edit mode" which seems not very intuitive in this case.
    c) The icon ignores all settings under "Desktop settings -> Icons", like sort order, icon size, align to grid etc.
    d) But you can do special things with such an icon: Make it incredibly big or small, or even rotate it ;-)

How could this be done better? I'm not completely sure how to do so without upsetting anyone, but here are some basic ideas how to make it less confusing:

* The copy/link here functionality makes perfect sense for normal files and folders when dragging them to the desktop. But it would make sense as well to treat .desktop files special, by merging "copy here" and "link here" to one entry titled "Add to desktop" (same as in Kickoff when you right click on a launcher), because I think that's what the expected behaviour when dragging a launcher to the desktop.
* The question is: Better link or copy? The current behaviour when you right-click on a launcher in Kickoff and you select "Add to desktop" is to link, and this may be the better solution because it avoids problem 1.b).
* If it gets decided that "Add to desktop" should mean "link desktop file", I would suggest to investigate if showing the "pure" app icon without the chain-symbol makes sense (problem 2.a)).
* If the "(Widgets) Add icon" functionality should be kept, perhaps there is a way to make it more clear what it does and how this is different from "Add to desktop".

Kind regards, Jan
Comment 1 Nate Graham 2021-11-24 17:54:39 UTC
This is one of the painful things that happens because of our flexibility. We don't offer only one way to do things, but rather multiple ones. But each one has non-obvious characteristics and traits and limitations and it just ends up being confusing for people.

One thing we could maybe do is remove the "Copy" menu item when dragging a desktop file from a launcher to the desktop. Actually duplicating the desktop file is almost certainly not what the user wants. That's probably worth a separate bug report as hopefully it shouldn't be controversial.

Of the remaining options, it's tricky. "Link" creates a Windows-style link that Windows users at least will be familiar with. Most of them have tons of links on the desktop. And this approach it has the advantage of being interactive as a normal filesystem item, because that's what it is. It's simple and familiar and comprehensible.

"Add icon" creates a Plasma launcher widget, which does not behave as a filesystem item, because that's not what it is. It's an applet that responds to a click. Putting launchers on the desktop is a somewhat uncommon thing. For that matter these days it's somewhat uncommon to even put launchers on a panel, since panels typically have a Task Manager applet on them, and these let you pin apps to them. So this also relates to Bug 390817. Not sure there's a good solution there.

If I could wave a magic wand, I'd universally remove the ability to create launcher applet via drag-and-drop and force people to manually add them. People who want them generally know what they want, whereas people who don't will often get them anyway by accident because they don't underatand the subste and unintuitive differences between these things.
Comment 2 Jan Rathmann 2021-11-26 11:08:27 UTC
Nate, thanks for your exhaustive reply!

If  I read your comment right, then the way forward could be:
* Remove "Copy here" item from menu when a launcher is dragged to the desktop
* Keep "Link here", maybe rename it to "Add to desktop"

Additional:
* Evaluate whether it makes sense to _not_ add the chain-symbol ("this is a symbolic link") on .desktop files on desktop.

Should I fill separate reports for the individual steps?

Regarding "Add icon:"
Still it doesn't seem that logical to me that applets/widgets that are actually launchers don't respect double-click settings when on deskop ;-) But maybe it would be hard to make that different than for all other widgets.
Comment 3 Nate Graham 2021-11-29 19:57:46 UTC
All applets activate themselves and do something when single-clicked. It just so happens that when Icon launcher icons are activated, they open a file or folder. So it's mixing two different paradigms. All the more reason why I would like to minimize the contact that users have with Icon launcher applets.

My preferred path forward would be:
1. Hide the "Move here " and "Copy" menu items for launchers dragged to the desktop. Those are just nonsensical and it never makes sense to use them. This should not be controversial IMO.
2. Hide the "Add icon" menu item for for launchers dragged to the desktop. This may be more controversial. Hance, it would ideally have a separate bug report to track it.

I wouldn't change anything about the link behavior. Links always get rendered in italic text with a link symbol everywhere else; IMO that convention should be followed on the desktop too.
Comment 4 Bug Janitor Service 2024-08-11 05:27:09 UTC
A possibly relevant merge request was started @ https://invent.kde.org/frameworks/kio/-/merge_requests/1683
Comment 5 Bug Janitor Service 2024-09-20 20:35:30 UTC
A possibly relevant merge request was started @ https://invent.kde.org/plasma/libplasma/-/merge_requests/1198
Comment 6 Nate Graham 2024-09-20 20:41:52 UTC
^^ That should take care of removing the "Add Icon" item.

Next up is to figure out a way to remove the Move and Copy items — but only when the drag originates from a launcher like Kickoff, Task Manager, or KRunner. We want to suppress them there, but still (obviously) allow moving or copying .desktop files dragged from a file manager app.
Comment 7 Bug Janitor Service 2024-09-21 15:30:42 UTC
A possibly relevant merge request was started @ https://invent.kde.org/frameworks/kio/-/merge_requests/1726
Comment 8 Bug Janitor Service 2024-09-21 15:33:48 UTC
A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-desktop/-/merge_requests/2537
Comment 9 Bug Janitor Service 2024-09-21 15:34:50 UTC
A possibly relevant merge request was started @ https://invent.kde.org/frameworks/krunner/-/merge_requests/183
Comment 10 Nate Graham 2024-09-22 20:31:03 UTC
Git commit 4aa2ce933d641be84438daa3e6317bf0dd9d56e3 by Nate Graham.
Committed on 22/09/2024 at 20:29.
Pushed by ngraham into branch 'master'.

Don't offer to create Icon widget when dropping .desktop files

When dragging-and-dropping apps from Kickoff/Task Manager/etc. to the
desktop, no fewer than four options can be presented, one of them being
"Add Icon". This one is a particularly poor choice because it becomes
a widget that looks like a normal file, but does not behave according
to the normal file semantics:

- It can't be drag-and-dropped or selected the same way
- It always opens on single-click
- It's harder to figure out how to remove
- It can overlap normal desktop icons

Fixing these issues is not really possible due to the nature of what an
Icon applet simply *is*; they are baked into its nature as a widget. As
such, Icon widgets are not very well suited for being on the desktop
most of the time, so let's remove the option from the drop mmenu.

M  +3    -19   src/plasmaquick/plasmoid/containmentitem.cpp

https://invent.kde.org/plasma/libplasma/-/commit/4aa2ce933d641be84438daa3e6317bf0dd9d56e3