Review Request 107708: [Dolphin] Fake click for short drag and drop on same item

[Thomas Lübking]

> On Jan. 13, 2013, 10:13 a.m., Frank Reininghaus wrote:
> > Thanks for the new patch. First of all, I appreciate that you spent so much time already to make the user experience better, and I'm sorry that this discussion takes so long. I see that it's also my fault because I might not have thought enough about the issue first. I was pretty sure that not starting the drag while the item is still hovered is the best approach, but you convinced me that this "late drag start" could also be irritating and annoying in some situations.
> > 
> > I think that there are two problems. They are independent at first sight, but their combination is what can annoy people badly:
> > 
> > 1. Sometimes, when a user clicks, the mouse moves a bit, such that a drag is started.
> > 2. The "A folder cannot be dropped on itself" message can be extremely annoying.
> > 
> > I can't help thinking that the best solution for issue 1 is to increase the startDragDistance - either each user for himself/herself or globally. Adding hacks to applications to reduce the negative consequences of unintended drag&drop is the wrong approach IMHO.
> > 
> > But maybe the best way to resolve this is to target issue 2? In most situations where drops are not allowed, the receiving widget just does not accept it, and the "drop forbidden" cursor is shown. Maybe we could do that as well, and show an unintrusive "A folder cannot be dropped on itself" message in the status bar while that happens? I guess that nobody would consider the unintended drag annoying if the message widget does not pop up. The user would just try again to click and be happy. (BTW, just checked Nautilus - it seems that "folder on itself" drops just fail silently there. Maybe another hint that the very intrusive message in the KMessageWidget is a bit too much.)
> > 
> > Thanks again for your work. It is greatly appreciated, I'm just trying to make sure that we really find a good solution for everyone, and I think that even users who see the "A folder cannot..." message in other situations might find it annoying and consider the "drop forbidden cursor" solution better.

You'r right about issue 1 - if the user constantly fails to perform a clean click s/he should increase the global DnD distance. The question which invokes issue 2 is whether and how much s/he should be punished[1] for a slight glitch.

The current patch fails silently for the first 500ms, assuming this is a mistake and the user did not meanwhile forget whst s/he's dragging or intentionally tries to drop a folder on itself.

The "drop forbidden" solution actually has a major defect, because it's (so far) perfectly fine to *drag* a folder on itself[2] where we now touch "file op policy" terms, ie. either one would prevent the hover signal in general (and block the DnD) or actually completely scratch the test or offer only link and copy as legal actions in the popup (but that would also require to validate the action for the full path, pot. resolving links - not only a "naive" source/destination compare)

[1] The message is kind of a "GUI disaster" ;-)
Much worse than the visual distraction is that it alters and indents the active GUI under the users fingertips. I'd consider to move it to the bottom if possible.

[2] To open it
This way one can create cyclic links on deeper layers - that's legal and not prevented (neither would be to create them on the first layer, but that's prevented) and actually dolphin will happily create a recursive copy. Move will fail on the kio layer with a "could not rename" error.


- Thomas


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/107708/#review25341
-----------------------------------------------------------


On Jan. 12, 2013, 4:09 p.m., Thomas Lübking wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/107708/
> -----------------------------------------------------------
> 
> (Updated Jan. 12, 2013, 4:09 p.m.)
> 
> 
> Review request for Dolphin and Frank Reininghaus.
> 
> 
> Description
> -------
> 
> When there's a relatively short click (i picked 500ms) and the item is moved to DnD and released on itself, this is now assumed a "dirty click" (ie. the user actually wanted to click, but juddered) instead of presenting a warning that an item cannot be dragged on itself.
> 
> Notes:
> - 500ms are quite some time. I can drag the icon out, back in and drop it in place.
> - due to the high abstraction level in the DnD processing and the application window being the drag source, it is technically possible to split the view and DnD an icon onto its other self within 500ms
> 
> I'm however willing to state that if you manage to do either of that, you should not have major issues on performing a regular click either.
> I picked the 500ms on personal test (started with 1500, what seems far too much)
> 
> - the reason for having the timeout in the first place is the assumption, that users may actually intentionally try to drag an item on itself. Either because they intend to link it there (link recursion can be dangerous, but is a legal action) or for "ummm... i didn't want to copy that folder. errr... how do i stop this ... ok, let's just put it back from where it came and hope for the best". Because of the latter i think this should be hinted after the message freeze.
> 
> - one might want to add a "don't ask again" checkbox to the hint and account that by dropping the timeout
> 
> 
> This addresses bugs 283646, 297414, 307747, and 311483.
>     http://bugs.kde.org/show_bug.cgi?id=283646
>     http://bugs.kde.org/show_bug.cgi?id=297414
>     http://bugs.kde.org/show_bug.cgi?id=307747
>     http://bugs.kde.org/show_bug.cgi?id=311483
> 
> 
> Diffs
> -----
> 
>   dolphin/src/kitemviews/kitemlistcontroller.cpp 697e04f 
>   dolphin/src/views/draganddrophelper.h ac16f7c 
>   dolphin/src/views/draganddrophelper.cpp f81d4d0 
> 
> Diff: http://git.reviewboard.kde.org/r/107708/diff/
> 
> 
> Testing
> -------
> 
> clickdragged a folder in both view (w/ and w/o scroll offset)
> 
> 
> Thanks,
> 
> Thomas Lübking
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.kde.org/mailman/private/kfm-devel/attachments/20130113/351b786e/attachment.htm>