After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 87074 - Dragging should begin after a timeout
Dragging should begin after a timeout
Status: RESOLVED OBSOLETE
Product: gtk+
Classification: Platform
Component: .General
2.8.x
Other other
: Normal minor
: Small API
Assigned To: gtk-bugs
gtk-bugs
: 44981 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2002-07-02 04:14 UTC by Ben FrantzDale
Modified: 2018-04-14 23:57 UTC
See Also:
GNOME target: ---
GNOME version: 2.9/2.10


Description Ben FrantzDale 2002-07-02 04:14:48 UTC 
The global drag & drop threshold found in the mouse preferences dialog is
not used by nautilus; a drag begins after moving the mouse only one pixel.

This was discussed on nautilus-list@gnome.org under the subject "PATCH for
some random stuff.".

One thing that should be kept in mind when fixing this is that there is
reason to have an additional timeout such that, if the DnD threshold is,
say, 10 pixles, draging something 2 pixels and waiting for some ammount of
time would still put it in drag mode. Otherwise you get into the problem of
not being able to move something over a little bit without first moving it
over a lot, then moving it back. (Perhaps such a timeout should also be a
global setting. If it were it might be one to only go in gconf, but not
have publicly accessable; 1/2 second is probably fine.)
Comment 1 Luis Villa 2002-07-30 19:59:28 UTC 
Indeed it should.
Comment 2 Dave Bordoley [Not Reading Bug Mail] 2002-09-02 06:38:28 UTC 
*** Bug 46868 has been marked as a duplicate of this bug. ***
Comment 3 Dave Bordoley [Not Reading Bug Mail] 2002-09-02 06:40:30 UTC 
*** Bug 44981 has been marked as a duplicate of this bug. ***
Comment 4 Dave Camp 2002-10-12 19:07:02 UTC 
The icon container uses the gtk drag threshold now.  Retitling to
accurately reflect what's left of the bug.
Comment 5 Christian Neumair 2005-09-14 22:06:55 UTC 
Reassigning to GTK+, since we need a more general framework for this, maybe
gtk_drag_check_threshold_full that also takes a start_time and current_time.
Comment 6 Matthias Clasen 2018-02-10 05:12:08 UTC 
We're moving to gitlab! As part of this move, we are moving bugs to NEEDINFO if they haven't seen activity in more than a year. If this issue is still important to you and still relevant with GTK+ 3.22 or master, please reopen it and we will migrate it to gitlab.
Comment 7 Matthias Clasen 2018-04-14 23:57:20 UTC 
As announced a while ago, we are migrating to gitlab, and bugs that haven't seen activity in the last year or so will be not be migrated, but closed out in bugzilla.

If this bug is still relevant to you, you can open a new issue describing the symptoms and how to reproduce it with gtk 3.22.x or master in gitlab:

https://gitlab.gnome.org/GNOME/gtk/issues/new