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 46276 - Should use middle mouse button for query-dragging
Should use middle mouse button for query-dragging
Status: RESOLVED FIXED
Product: nautilus
Classification: Core
Component: Views: All
0.x.x [obsolete]
Other Linux
: Normal enhancement
: future
Assigned To: Nautilus Maintainers
Nautilus Maintainers
Depends on:
Blocks:
 
 
Reported: 2001-02-02 21:43 UTC by John Sullivan
Modified: 2004-12-22 21:47 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
proposed fix (3.70 KB, patch)
2002-11-11 19:04 UTC, Marco Pesenti Gritti
none Details | Review

Description John Sullivan 2001-09-10 00:58:09 UTC
This bug was inspired by an email discussion with jrb@redhat.com.

Currently we use the right mouse button for two distinct actions when clicking
on an icon in icon or list view: popping up a context menu, and initiating a
"query drag" (a drag where the user gets to choose which action (move/copy/link)
they intended when the drag is completed). In order to determine the user's
intention of context-menu-vs-drag, if the button is pressed but not immediately
released we wait for a timeout before displaying the context menu. If during
that timeout the mouse moves more than some tiny hysteresis, we start a drag and
the context menu never appears. If the button is pressed and released right
away, the context menu appears right away.

The GTK drag-and-drop framework uses the middle mouse button for "query
dragging". Nautilus is varying from that standard by using the right mouse
button.

This bug is about the decision of which button to use. The arguments as I
understand them are like this:

In favor of right button:
(1) Many people have two-button mice. Chording (using the combo of two buttons
to simulate the missing third button) is possible but very awkward.
(2) Windows and Be both use the right button for "query dragging", so many
people will expect it there, and will never discover it if it's on the middle
button.
(3) Having different actions on all three mouse buttons requires more work from
the user to remember which is which.

In favor of the middle button:
(1) It is the GTK/GNOME standard, used by other GTK/GNOME apps that implement
drag and drop. (The only one I know of for sure that does this is GMC, but
that's just because I'm not familiar with many GTK/GNOME apps. Jonathon says it
is the default behavior and I believe him.)
(2) Differentiating the query-drag action from the context menu action makes the
context menu behavior much smoother. In particular, there's no timeout (the menu
appears instantly on mouse-down) so you can choose a menu item more quickly, and
there's no possibility of accidentally starting a drag when you meant to choose
a menu item (provided you use the right button).

I think Jonathon has a very good point. I think the arguments for changing to
the middle button are stronger than the arguments for continuing to use the
right button. But others may disagree. I'd really like to hear opinions from
Arlo, Andy, and Pavel about this.



------- Additional Comments From brett@eazel.com 2001-02-02 16:52:37 ----

X has a setting for "emulate 3 buttons" which uses a two-button chord, but this
is not a default setting.  I use a two-button mouse and usually have to enable
this manually with Xconfigurator or XF86Setup after installation.



------- Additional Comments From jrb@redhat.com 2001-02-02 17:01:22 ----

Most distributions (that I know of) turn on middle button emultation by default.
Additionally, quite a few other things (cut-n-paste, panel moving, etc.) in
GNOME/X do require a 3rd button.  Whether or not you think using the 3rd mouse
button is good or not, this hardly seems to be the place to take a stand against it.




------- Additional Comments From brett@eazel.com 2001-02-02 17:04:21 ----

My comment doesn't intend to reflect an opinion either way.  It exists mostly to
point out that we need to assure that this setting is enabled for
two-button-mouse users, or account for it in post-install configuration and user
documentation.



------- Additional Comments From sullivan@eazel.com 2001-02-05 09:58:30 ----

Leaving this one to Don to set priority.



------- Additional Comments From pavel@eazel.com 2001-02-05 12:25:10 ----

I have a problem with this, middle mouse buttons are second-class citizens in
general and specially on X:

Lot of mice out there have a middle button that is less accessible than the
other two buttons - for instance on some Microsoft and Logitech mice it is tied
to the wheel. Clicking on the wheel may seem awkward to some users.

There are a lot of mice with two buttons only, namely pretty much all the
laptops.
Using a two-button mouse to emulate the middle button by pressing the two
buttons is tricky - it is OK if all you need to do is click to paste an X
clipboard. Clicking the two buttons and doing a drag is a different thing all
together, it's quite an unplesant acrobatic operation.

Last but not least, the middle mouse button emulation feature is pretty broken
on X -- if you for instance have a laptop and most of the time you use it you
attach an external three button mouse to it, you will want to set your mouse to
be the external one. Turning on the "emulate middle button" feature makes your
external mouse work sub-optimally, on my setup the wheel mouse and the middle
button stop working. Having it off obviously makes the middle button
unaccessible when you disconnect the external mouse and use the builtin trackpad
or what have you.
On other operating systems this is not a problem because the system will
reconfigure itself automatically to optimally support the mouse you have
attached.



------- Additional Comments From don@eazel.com 2001-02-06 12:04:58 ----

Over to me to decide.  I'll talk to Arlo




------- Additional Comments From don@eazel.com 2001-02-12 20:51:42 ----

Sorry, but I agree with Pavel.  (Shoot me full of arrows now. ;)

Perhaps we could make this some kind of power-user hidden preference, but it's
not something we have time for in 1.0.




------- Additional Comments From mjs@noisehavoc.org 2001-02-12 20:57:09 ----

I think using the right button for this is irksome. I don't think this feature
is very discoverable either way (which really sucks, because there is _NO_
discoverable way to copy or create a link other than Duplicate or Create Link
and then drag and rename back to the orignal name, which is sucky), and the
extra delay on the right click menu is high enough to be noticable and annoying.

So I'm unhappy to see this RESOLVED WONTFIX, but I won't unilaterally reopen it.

My personal feeling though, is that query-drag is an undiscoverable power-user
feature and should not take precedence over right-click context menus, which are
popular and commonly used.




------- Additional Comments From sullivan@eazel.com 2001-02-12 22:12:19 ----

I agree with Maciej overall. Though all of Pavel's points are valid, the main 
arguments that sway me away from using right-button-drag for 
query-dragging are (1) it gets in the way of the more common interaction 
of using the context menus, and (2) you can query-drag with the left button 
already, by using the Alt modifier. I also will shy away from reopening this 
bug though.

Added Don to cc: list so he'll see these last feeble protests.



------- Additional Comments From arlo@workthatmouse.com 2001-02-13 00:44:30 ----

Count me in on wanting this to be a middle button feature.



------- Additional Comments From mjs@noisehavoc.org 2001-02-13 06:29:58 ----

Don, given the most recent comments of myself, arlo and sullivan, you could
consider reopening this and moving to 1.0.1 or deferred instead of leaving it
RESOLVED WONTFIX.

Just to add more fuel to the fire, the first couple of times I got the
query-drag menu I had no idea what I'd even done to make it come up, because I'd
been trying to get the right-click context menu but slipped. I thought it was
some bizzaro bug or that I'd accidentally hit some random modifier key.




------- Additional Comments From brett@eazel.com 2001-03-07 20:34:58 ----

Reopening (impartially) because the most recent comments in this bug report
suggest re-evaluation.  (i.e., i can't verify this bug in its current state.) 
This bug should definitely be handled after 1.0.



------- Additional Comments From don@eazel.com 2001-03-07 21:26:45 ----

Not a 1.0 blocker.




------- Additional Comments From vera@eazel.com 2001-03-12 11:47:51 ----

Adding myself to list of cc's



------- Additional Comments From eli@eazel.com 2001-03-26 11:10:50 ----

QA Assigning to self.



------- Bug moved to this database by unknown@bugzilla.gnome.org 2001-09-09 20:58 -------

The original owner (don@eazel.com) of this bug does not have an account here.
Reassigning to the default owner of the component, nautilus-maint@bugzilla.gnome.org.

Comment 1 John Fleck 2002-01-05 04:23:00 UTC
Changing to "old" target milestone for all bugs laying around with no milestone set.
Comment 2 Marco Pesenti Gritti 2002-11-11 19:04:47 UTC
Created attachment 12231 [details] [review]
proposed fix
Comment 3 Alexander Larsson 2002-11-28 10:10:15 UTC
I agree with using middle-button for this. For two-button mice
Alt-drag is already availible. Query-dragging is a seldom used feature
that should not impede on usage of the context menu.
Comment 4 Alexander Larsson 2002-11-28 10:55:58 UTC
Now in cvs.