GNOME Bugzilla – Bug 346609
[PATCH] Quartz backend has no support for one-button mice
Last modified: 2011-09-28 20:42:17 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.
Created attachment 68379 [details] [review] Patch to enable mouse button emulation
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?
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...
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.
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!
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.
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.
Created attachment 109973 [details] [review] Patch to enable mouse button emulation Same patch, fixed up for current Gtk.
(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.
(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.
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.
Created attachment 109991 [details] [review] Remap alt/meta Slightly related to this bug, a patch that does the mentioned change of modifiers.
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.
(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.
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..
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.
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?
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
> 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.
(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.
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.
(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.
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)
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?
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.
This bug is fixed by the recent work in both master, gtk-3-2 and gt-2-24, the attached patch is obsolete.