Disallow drop of task manager icons outside of plasmoid when widgets are locked
AbandonedPublic

Authored by emateli on Oct 31 2017, 8:58 AM.

Details

Reviewers
plasma-devel
Group Reviewers
Plasma
VDG
Summary

BUG: 361984

This patch disallows dropping task manager items outside of the plasmoid when widgets are locked.
As a user whose primary device is a laptop (with a touch screen at that) I find myself involuntarily dragging task manager icons to other applications, such as a maximized browser window or a code editor. This leads to .desktop files being dropped in various applications, which I can assume is not something one wants to do very often(if at all?).

This patch disables this functionality when widgets are locked. When they are unlocked the behaviour stays the same(so icons can be dragged into the desktop and so on).

This affects "Task Manager" and "Icons-Only Task manager" plasmoids.

Test Plan

Have a panel with task manager

  • Lock widgets
  • Try to drop icons outside of panel

Diff Detail

Repository
R119 Plasma Desktop
Branch
disable-drop
Lint
No Linters Available
Unit
No Unit Test Coverage
emateli created this revision.Oct 31 2017, 8:58 AM
Restricted Application added a project: Plasma. · View Herald TranscriptOct 31 2017, 8:58 AM
emateli retitled this revision from Disallow drop of task manager widgets outside of plasmoid when locked to Disallow drop of task manager icons outside of plasmoid when widgets are locked.Oct 31 2017, 8:59 AM
hein added a subscriber: hein.Nov 1 2017, 11:45 AM

As-is I would not accept this patch, I'm sorry. Task Manager items are not widgets, it's content, and the widget mutability state should not affect content drags.

This particular drag is used for workspace features some people do rely on, e.g.:

  • moving a window to a different virtual desktop or activity by dropping it somewhere on the Pager widget
  • adding a launcher button or menu favorite somewhere

If accidental drags are a frequent issue, perhaps we need to address it in some other way.

emateli updated this revision to Diff 21688.Nov 1 2017, 11:58 AM

Allow task items to be dropped onto other widgets

emateli updated this revision to Diff 21689.Nov 1 2017, 11:59 AM

Remove empty line

Hi @hein, thanks for your input and I understand that this might break some functionality that I'm unaware of (such as the drop of task manager icons into the pager widget).

The current revision allows drop into the pager widget and other plasma widgets(needs more testing on this) and the incoming drops are accepted. So from the launcher one can still drop icons to create shortcuts.
This patch is mostly so that drops from the task manager do not go into external programs. Also, even in it's current form dropping task manager icons to a desktop with locked widgets will not create the shortcut regardless.

hein added a comment.Nov 1 2017, 12:10 PM

I still don't like it, sorry - the patch also feels technically and semantically wrong to me. "If widgets are locked, stop adding a certain kind of data to the drag" is a pretty bad hack.

romangg added a subscriber: romangg.EditedNov 1 2017, 12:17 PM

That said accidental drags from the task manager are really a common issue. Could we do some sort of double-tap-and-drag instead of just drag to minimize the risk for an accidental drag?

EDIT: What's also an idea (and what's a common workflow in mobile) is a long holded press (>500ms) with left button is needed on the item for enabling dragging. Otherwise it registers a single click.

I feel like the long press can mess with the manual ordering of task manager icons.

Sounds like we want what is something similar to 86bbebdee213f08ae615d7459304cbd17f6b7d7d in kdeclarative's DragArea

romangg added a comment.EditedNov 1 2017, 1:02 PM

I feel like the long press can mess with the manual ordering of task manager icons.

Short press

Press -> start timer
release -> single click on task
timer stops

Press -> start timer
move mouse but stays in task
release -> single click on task
timer stops

Press -> start timer
cursor leaves task but stays in task manager area
start drag confined to task manager
release-> manual reorder tasks
timer stops

Press -> start timer
cursor leaves taskbar
release -> single click on task
timer stops

Press -> start timer
cursor leaves taskbar
timer stops
release -> noop

Long press

Press -> start timer
timer stops
release -> single click on task

Press -> start timer
timer stops
move mouse
start drag
cursor leaves task but stays in task manager area
release-> manual reorder tasks

Press -> start timer
timer stops
move mouse
start drag
cursor leaves taskbar
release->drag

Task Manager items are not widgets, it's content, and the widget mutability state should not affect content drags.

I don't see why it can't. Task manager items can be aware of the panel state if that's needed.

"If widgets are locked, stop adding a certain kind of data to the drag" is a pretty bad hack.

What would you propose? I tried cancelling the drag once it moved outside of the panel but it wouldn't work. Right now the task manager doesnt need the URL list for it's operations to work.
By removing it, external apps do not accept the drop which is kind of what we want. Also as previously mentioned the only valid drop target I can see for them is the desktop, which in it's current state does not create the shortcut if widgets are locked anyways.


Also please help me out here since maybe I'm missing something. But is the dragging around into external applications of .desktop files a feature that we want? I always assumed it was a sort of bug or something that was simply not handled since I really don't see a use for it, but I'm also not well versed in everything Plasma does.

ngraham added a subscriber: ngraham.Nov 1 2017, 6:54 PM

FWIW, I do approve of the goal here. I can't imagine that any more than a very very tiny fraction of all drags to the desktop or into a web browser or text editor window are intentional.

hein added a comment.Nov 2 2017, 8:53 AM

What would you propose?

To be honest - dropping the patch.

But is the dragging around into external applications of .desktop files a feature that we want?

Sure. The URL to the .desktop file is the exchange-ready representation for an app, which the task item is a delegate for. I don't see a good reason not to be able to drag one, considering you can do elsewhere in UI (launchers, file view items, ...). It's just consistent DND support in the system.

To be honest - dropping the patch.

I feel as that's the easy part.

Sure. The URL to the .desktop file is the exchange-ready representation for an app, which the task item is a delegate for. I don't see a good reason not to be able to drag one, considering you can do elsewhere in UI (launchers, file view items, ...). It's just consistent DND support in the system.

But is it necessary though to be performed from the Task Manager? That leads only to unwanted behavior. If one really wants to do that or has a use case for it then I assume KRunner or the Application Launcher can pick up the slack. Also I think it's note worthy that as you probably know no major (and I say major to cover my bases, but it's probably all of them) DE supports this kind of behavior. Maybe they missed the memo on this being a useful feature.

I think the question we need to ask ourselves is whether the ability to create .desktop shortcuts by dragging from the task manager is useful to enough people to outweigh the confusion and frustration to other people caused by unwanted drags.

As a compromise, maybe we could only start a drag operation if the mouse goes 50-100 pixels beyond the task manager? This is what the macOS Dock does to prevent unwanted drags: If you drag-and-drop within a hundred pixels of the Dock, the icon springs back.

ngraham edited the summary of this revision. (Show Details)Dec 14 2017, 10:09 PM

I found at least one user during my triaging of Task Manager bug who was sufficiently motivated to file a bug that this would resolve: https://bugs.kde.org/show_bug.cgi?id=361984

I found at least one user during my triaging of Task Manager bug who was sufficiently motivated to file a bug that this would resolve: https://bugs.kde.org/show_bug.cgi?id=361984

I don't think that just because we have a bug report, that should influence on which direction this patch takes. I personally view it as a basic usability problem. It's easily reproducible on laptop touchpads, and happens every once in a while in desktops as well (especially when the system hangs even for half a second at the moment you click a task icon).

The feature(??) this provides is such a rarely used case(if ever) for it to be on such a prominent place. Anyhow, since we're at it, let's discuss it once more and see if we can reach a decision whether this is a positive change that we want to go in or not. I've made my case on why this should go in in the previous comments. Other than that, if the implementation is the correct one or not, it's an entirely different matter.

We discussed the matter in the VDG Telegram room this morning and came up with some alternative ideas:

  • Ignore drag operations that fall below a certain threshold, to only allow clear and purposeful drags and filter out accidental drags caused by imprecise input devices or low mousing skills
  • Activate Taskbar button on click, not release

Both of these together would probably be pretty nice, and also mirror the draggable tab behavior in most apps.

ngraham added a reviewer: VDG.Dec 15 2017, 5:34 PM
emateli abandoned this revision.Dec 18 2017, 4:59 PM

Closing this since we're unable to reach a consensus. None of the proposed changes are how I envision the patch to work.

hein added a comment.Jan 1 2018, 1:50 PM

Sorry Emirald.