GNOME Bugzilla – Bug 637103
dragging icons in dash is hard
Last modified: 2012-03-20 01:47:13 UTC
1. hold down pointer button on upper part of any icon in dash 2. immediately start moving down with button still pressed 3. if you don't leave the icon with the pointer before the menu comes up you won't be dragging the launcher One thing that would probably help is to not start the timeout for showing the menu until the mouse stops moving (with some tolerance for wiggle). We'll have to think about how dnd will be initiated on touch devices at some point.
*** Bug 647057 has been marked as a duplicate of this bug. ***
Created attachment 206208 [details] [review] Wait that the mouse doesn't move (too much) before showing the menu I've implement the solution proposed by wiliam in this patch, except that the timeout is started like before but I check that the mouse hasn't moved too much before showing the menu.
Created attachment 206613 [details] [review] Typo fix
Review of attachment 206613 [details] [review]: I must say that I don't like this approach - we are already using a threshold, see http://git.gnome.org/browse/gnome-shell/tree/js/ui/dnd.js#n338 What is happening here is that we are not using it in this particular case, see http://git.gnome.org/browse/gnome-shell/tree/js/ui/dnd.js#n123 So I think rather than duplicating the threshold from dnd, we should try to make it work (without messing up the St.Button state of course, which is why the special handling was introduced in the first place). I suspect that moving the special handling to startDrag() instead would do the trick.
Created attachment 210120 [details] [review] dnd: Improve special-handling of St.Button To avoid messing up St.Buttons' internal state with a pointer grab, we wait for the pointer to leave the actor before starting the drag operation manually. This works generally fine, but makes starting a drag operation harder than necessary. To fix, remove the special handling before starting the drag and enforce a reasonable button state after releasing the grab. My shot at the solution outlined in comment #4.
Review of attachment 210120 [details] [review]: Im pretty sure that the behavior isn't accidental workaround for the internals of St.Button but rather was an interpretation of what we thought the design was. And there is a question of whether this is going to make it hard on a touch-screen device to trigger the press-and-hold menu. But in general, I think it's likely better - I've always thought the leave-to-start-dragging was a bit off.
Created attachment 210130 [details] [review] dnd: Improve special-handling of St.Button "Updated" patch - this is the version I've tested the last couple of days, but then I decided to move some code while writing the commit message because it made more sense. Unfortunately that broke "normal" clicks on dash items, so here's my original shot at the issue.
Review of attachment 210130 [details] [review]: Sure
Attachment 210130 [details] pushed as b3358ae - dnd: Improve special-handling of St.Button Closing as fixed - with the patch, the dash now uses the same threshold parameters as Gtk+/Clutter (which Clutter also uses to cancel long-presses); if there are still issues, they won't be limited to the dash and are probably better addressed by tweaking the parameters themselves.