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 346609 - [PATCH] Quartz backend has no support for one-button mice
[PATCH] Quartz backend has no support for one-button mice
Status: RESOLVED FIXED
Product: gtk+
Classification: Platform
Component: Backend: Quartz
2.10.x
Other Mac OS
: Normal normal
: ---
Assigned To: Richard Hult
gtk-bugs
Depends on:
Blocks:
 
 
Reported: 2006-07-05 06:04 UTC by Dave Vasilevsky
Modified: 2011-09-28 20:42 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Patch to enable mouse button emulation (3.39 KB, patch)
2006-07-05 06:04 UTC, Dave Vasilevsky
needs-work Details | Review
Patch to enable mouse button emulation (1.75 KB, patch)
2008-04-27 07:14 UTC, Yevgen Muntyan
none Details | Review
Remap alt/meta (1023 bytes, patch)
2008-04-27 15:50 UTC, Richard Hult
none Details | Review
mac ctrl and cmd keys (1.33 KB, patch)
2008-10-26 04:08 UTC, Yevgen Muntyan
none Details | Review

Description Dave Vasilevsky 2006-07-05 06:04:13 UTC
Please describe the problem:
Many Macs have mice with only one button, but Gtk expects (at least) three. Many Gtk apps depend heavily on the third/right mouse button, and are nearly impossible to use with only the first/left button. Apple's convention is to hold down the control key while left-clicking to emulate a right-click, and the quartz backend should follow this convention.

Steps to reproduce:
1. Attach a one-button mouse to your computer
2. Copy some text from any application to the clipboard
3. Run tests/testtext
4. Attempt to paste the text, by control-clicking to popup a context menu.

Actual results:
There exists no apparent way to paste the text.

Expected results:
The context menu pops up, and "Paste" can be chosen.

Does this happen every time?
Yes

Other information:
The patch interprets any left-mouse-button action with control held to be a right-mouse-button action. Unfortunately, control-left-click is commonly used in GTK for multiple selection. But happily, command-click (meta-click) is usually used on the Mac for multiple selection, and is rarely used is GTK--so we can safely interpret command-left-click as control-left-click.

No solution is provided for middle-clicks, which are needed much more rarely than left- or right-clicks. It would be possible to add support for middle-click emulation if this becomes an issue, using some esoteric combination like command-option-click.

Some applications and their users may require the use of meta-click, so a #define is provided in gdkevents-quartz.c to allow mouse button emulation to be enabled or disabled when GTK is compiled. It might be better for this to be some sort of runtime option instead.
Comment 1 Dave Vasilevsky 2006-07-05 06:04:46 UTC
Created attachment 68379 [details] [review]
Patch to enable mouse button emulation
Comment 2 Richard Hult 2006-07-11 08:29:32 UTC
I wonder if maybe we should take another approach and make the builtin widgets that have context menus handle ctrl-click instead of doing it globally?

Comment 3 Matthias Clasen 2006-07-11 13:02:01 UTC
Whatever we do here should probably be coordinated with the desires of
touchscreen-mode people. A touchscreen is a lot like a one-button mouse,
from some perspectives...
Comment 4 Dave Vasilevsky 2006-07-12 12:32:43 UTC
I do think it's appropriate to do this at the GDK level, rather than by changing individual widgets. I'd rather change one place in GDK than dozens of standard widgets--and this way custom widgets get support for free. There may be the rare widget which considers meta-click meaningful and does not want to have it remapped, I'm not sure if there's any good way to let a widget opt-out...

There is indeed a sort of similarity with touchscreens. It looks like libgtkstylus would work on the Quartz GDK with a couple of smallish changes. Unfortunately, the conventions that touchscreens and OS X have for how right-clicks should be emulated are different, and widgets which work well with one won't necessarily work well with the other.
Comment 5 Yevgen Muntyan 2008-04-27 06:49:27 UTC
Another way to reproduce this: use an application which has certain command available only in the context menu without a keyboard shortcut, get used to that nice command in that nice application, take my mac laptop and try to use that application. Guys, please please please fix this! It at most may be left to the application to decide if it wants mac behavior or not; user needs the Control-Click!
Comment 6 Richard Hult 2008-04-27 07:09:38 UTC
It's not just a matter of hard coding control click to a right-click, that will mess up things that already use control-click (selection in treeviews, gimp, etc). Feel free to come up with a solution that doesn't break those cases.

Comment 7 Yevgen Muntyan 2008-04-27 07:13:38 UTC
Command-click for selection, like everywhere, no? I don't understand what you're saying, by that reasoning Gtk applications must use Control-C for Copy because they already use Control-C for Copy.
Comment 8 Yevgen Muntyan 2008-04-27 07:14:22 UTC
Created attachment 109973 [details] [review]
Patch to enable mouse button emulation

Same patch, fixed up for current Gtk.
Comment 9 Richard Hult 2008-04-27 07:38:06 UTC
(In reply to comment #7)
> Command-click for selection, like everywhere, no? I don't understand what
> you're saying, by that reasoning Gtk applications must use Control-C for Copy
> because they already use Control-C for Copy.

That's definitely not what I meant :) I actually meant that apps already using -command- click will break (do s/control/command/ in my comment). But as the original comment says, those might be very rare.

One thing we should do before or in combination with this is to swap meta and alt, they are currently mixed up.

Comment 10 Yevgen Muntyan 2008-04-27 07:50:40 UTC
(In reply to comment #9)
> (In reply to comment #7)
> > Command-click for selection, like everywhere, no? I don't understand what
> > you're saying, by that reasoning Gtk applications must use Control-C for Copy
> > because they already use Control-C for Copy.
> 
> That's definitely not what I meant :) I actually meant that apps already using
> -command- click will break (do s/control/command/ in my comment). But as the
> original comment says, those might be very rare.

But they can't really use Command right now, right? Since Command is really Alt, so they really use Alt and everything is broken, no? I would think that maintaining compatibility in this case is not something Gtk is committed to :)

> One thing we should do before or in combination with this is to swap meta and
> alt, they are currently mixed up.

This one really puzzled me. Option key is ignored right now, and Command is mapped to MOD1 which is Alt. What's going to be Command, GDK_MOD_SOMETHING? It'd be very nice to add GDK_COMMAND constant too.
Comment 11 Richard Hult 2008-04-27 11:59:51 UTC
The plan is to make command map to meta and alt to mod1. This should make things map quite well to X, so most apps will work well without modifications.

Doing that in combination with a key bindning theme that remaps ctrl-[xcv] to meta-[xcv] for editable widgets will make things work quite well I think.

Regarding the patch here, there is one concern left. The current event handling makes sure that we behave like X when it comes to the modifier state in the various events, and changing this looks like it could easily break that. A good test case here is gimp which makes heavy use of the state and relies on it behaving correctly. I can try to test the patch and see how it works. Can't promise when though.

Comment 12 Richard Hult 2008-04-27 15:50:40 UTC
Created attachment 109991 [details] [review]
Remap alt/meta

Slightly related to this bug, a patch that does the mentioned change of modifiers.
Comment 13 Owen Taylor 2008-09-01 15:05:13 UTC
Doesn't command map (more or less) to Alt in the PC world? It's the primary modifier key and immediately to the left of the spacebar, right? For historical reasons, "Alt" in GTK+ is represented by GDK_MOD1_MASK.

For Option, there has been convergence on mapping the "Windows" key to Super, so  I would suggest using GDK_SUPER_MASK for that.
Comment 14 Dan Winship 2008-09-01 16:31:25 UTC
(In reply to comment #13)
> Doesn't command map (more or less) to Alt in the PC world? It's the primary
> modifier key and immediately to the left of the spacebar, right?

Isn't the "primary modifier key" in the PC world Control?

Command is physically in the same place as Alt, but is used for a completely non-overlapping set of functionality:

                           Mac              Linux
Activate Menu Item         Command+key      Control+key
Single-select              Command+click    Control+click
Activate Context Menu      Control+click    Right click
Emacs/readline "C-x"       Control+x        Control+x(*)
Emacs/readline "M-x"       Option+x(*)      Alt+x(*)
Non-ASCII chars            Option+key       Alt-Gr+key
Activate Menu              -                Alt+key

(*) == in some apps / optionally, if you want to lose some of its standard functionality

So mapping Command to Alt is nice from a "make your finger memory transfer easily from Linux to Mac" perspective, but not from a "make GTK apps on OS X behave like native apps" perspective.
Comment 15 Owen Taylor 2008-09-01 18:44:31 UTC
You are right about the mapping being more that way (take the edit *-x,*-c,*-v shortcuts), but isn't trying to do this level of translation automatically a bad idea? It's a pretty confusing programmer interface if:

 Control => GDK_MOD1_MASK
 Command => GDK_CONTROL_MASK

I think. And you could imagine weirdness in user interfaces too ... like the GIMP tips in the status bar "Hold down control to .."

We could possibly an extra "virtual modifier", so that:

 GDK_ACCELERATOR_MASK => set for control or command depending on platform
 
And clued-in programmers could use that instead of GDK_CONTROL_MASK for menu shortcuts. I don't know how you handle user interface strings with that (other than %s gdk_get_accelerator_key_name()), but at least the programmer is in charge..
Comment 16 Richard Hult 2008-09-01 20:16:29 UTC
I think the best way to make GTK+ apps feel native on mac is to have:

Command key -> meta
Control key -> control
Option key -> mod1

+ providing stock shortcuts using command on mac, either by providing a mac binding rc file or by changing the source to use a platform dependant macro for the modifier.

Trunk already has the keys mapped like above. The problem is that the input methods currently filter out everything with mod1 which makes it impossible to enter things that need the option key like @ on some layouts. There is another bug report that deals with that that I can't find right now, searching seems to take forever.

For the input method issue, I was thinking about having an GDK_INPUT_ACCELERATOR_MASK which would be control on linux/win32 and control|mod1 on mac. Or perhaps try to figure out why the filtering is done in the first place, it's not quite clear to me.
Comment 17 Owen Taylor 2008-09-02 04:11:59 UTC
What's the reasoning? The best explanation I can come up with for your suggestion:
 
 Command is mapped to Meta as to make sure that it never interferes with any accelerators people have assigned in their app. (Meta is pretty much entirely unused in GTK+ programs)

 Option is mapped to MOD1 so that all the accelerators (or mnemonics) that people do have in their apps are accessible in some fashion. 

Can you give a code pointer for what you are talking about about input methods?
Comment 18 Richard Hult 2008-09-02 06:22:12 UTC
Command is mapped to meta to leave room for moving accels from control to command.

Option is mapped to mod1 because it is a modifier used to produce extra symbols on the keyboard (so it's not just used for accelerators).

Here's the input method problem, I remembered it slightly wrongly but it still is relevant: http://bugzilla.gnome.org/show_bug.cgi?id=531599

Comment 19 Owen Taylor 2008-09-02 12:25:00 UTC
> Option is mapped to mod1 because it is a modifier used to produce extra symbols
> on the keyboard (so it's not just used for accelerators).

that doesn't make any sense. MOD1 is Alt not AltGr. (Are there PC keyboard layouts where Alt produces alternate symbols? That would seem to conflict with normal usage of Alt.)

I can't make heads or tails of that gtkimcontextsimple.c bit of code.... but basically you'll have to decide whether Option should act like Alt or AltGr. "Both" seems problematic.
Comment 20 Richard Hult 2008-09-02 13:10:55 UTC
(In reply to comment #19)
> > Option is mapped to mod1 because it is a modifier used to produce extra symbols
> > on the keyboard (so it's not just used for accelerators).
> 
> that doesn't make any sense. MOD1 is Alt not AltGr. (Are there PC keyboard
> layouts where Alt produces alternate symbols? That would seem to conflict with
> normal usage of Alt.)

Yes, ignore that part, I got it backwards. I actually wanted to say that option corresponds to alt, but also has to be used as alt-gr.

> I can't make heads or tails of that gtkimcontextsimple.c bit of code.... but
> basically you'll have to decide whether Option should act like Alt or AltGr.
> "Both" seems problematic.

It's how things work with native mac apps though.

Comment 21 Dave Vasilevsky 2008-09-02 14:03:17 UTC
It should be noted that the Option key actually has Alt written on it as well, this has been the case for years: http://2aday.files.wordpress.com/2007/08/apple-bt-keyboard.jpg.

Stepping back and looking at everything from greater distance, I think the essential problem is that we're trying to decide "what key should correspond to what other key", rather than "what key(s) should accomplish which role(s)". A macro like GDK_ACCELERATOR_MASK was already suggested. Why not take that further, at least in the long-term?

GDK_ACCELERATOR_MASK1: Primary accel key, Ctl on Lin/Win, Cmd on Mac
GDK_ACCELERATOR_MASK2: Secondary accel key, Alt/Option
GDK_EXTEND_SELECTION_MASK: Ctl/Cmd
GDK_POPUP_MENU_MASK: nothing on Lin/Win, Ctl on Mac
etc.

This way we don't have to argue about "how can Option be Alt if it's also AltGr?". Each key is just in a set of roles.
Comment 22 Christian Dywan 2008-09-02 14:26:58 UTC
(In reply to comment #21)
> GDK_ACCELERATOR_MASK1: Primary accel key, Ctl on Lin/Win, Cmd on Mac
> GDK_ACCELERATOR_MASK2: Secondary accel key, Alt/Option
> GDK_EXTEND_SELECTION_MASK: Ctl/Cmd
> GDK_POPUP_MENU_MASK: nothing on Lin/Win, Ctl on Mac

Incidentally, there are linux applications, too, which make use of Ctrl when there is only one mouse button available.
Comment 23 Yevgen Muntyan 2008-10-26 04:08:07 UTC
Created attachment 121370 [details] [review]
mac ctrl and cmd keys

Above two patches combined, working with svn trunk.

By the way, Qt maps Command key to CONTROL enum, Control key to META, and it works pretty well. (And ctrl-click is seen as right-click by the program)
Comment 24 Mikayla Hutchinson 2009-02-25 21:37:28 UTC
In MonoDevelop, we allow arbitrary user-specified keybindings. This means that we can deal with the command/control issues simply by having a custom keybinding scheme for Macs. Automated mapping of Command to control will just make things harder for us.

Sometimes (usually?) on Linux, shift turns the alt key into the meta key. In order to bind "Shift-Alt" as such, instead of confusingly calling it "Shift-Meta", we have mapped meta back to alt.

The problem with this is that our Mac users are unable to bind command (meta) independently of alt.

Is there a sane solution to this?

Is there a good reason for not mapping Command/Apple as Super/Windows, for consistency with other systems?
Comment 25 Christian Hergert 2009-07-20 02:15:13 UTC
Is there a way to separate the support for CTRL+Click from the support for mapping of meta-keys?

1) Handle CTRL+Click in the quartz event generation and alter the button id to that of a right click
2) Support Command+{c,v,x} in GtkEntry and other text widgets (perhaps through the gtkrc as Richard provided in #530351).

Then we can at least get reasonable support for these out in 2.18 while deferring how we should handle trying to map shortcuts.
Comment 26 Michael Natterer 2011-09-28 20:42:17 UTC
This bug is fixed by the recent work in both master, gtk-3-2 and gt-2-24,
the attached patch is obsolete.