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

Frank Reininghaus frank78ac at googlemail.com
Sun Jan 13 10:13:00 GMT 2013


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


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.

- Frank Reininghaus


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/51f5e182/attachment.htm>


More information about the kfm-devel mailing list