GNOME Bugzilla – Bug 530351
Use standard mac shortcuts
Last modified: 2009-11-14 01:27:14 UTC
Attached patch changes Ctrl-X, Ctrl-C, etc. to Cmd-X, Cmd-C, etc. It changes only those common shortcuts and doesn't touch things like "go to parent folder" in GtkFileChooser.
Created attachment 110036 [details] [review] patch
Mac bindnings should not be done by patching the source but by providing a gtkrc.
(In reply to comment #2) > Mac bindnings should not be done by patching the source but by providing a > gtkrc. This is wrong unless it's desired that widgets have both mac and linux bindings. Is that really desired? I'd think an application may want to use Ctrl-A for its own purposes, and binding it to Select All only because it's Select All on linux is wrong.
The idea was of course that the keybinding theme would unbind the "linux" binding. Or do you mean that wouldn't work?
Not as far as I can see. Perhaps there is a way to remove other bindings but it's undocumented. To see that the usual bindings gtkrc thing won't remove anything, try the emacs one from gtk directory - both emacs and normal gui shortcuts will work. I have the gtkrc with mac shortcuts here, I just don't think it's a right thing to do. Plus you got to patch Gtk anyway - not all shortcuts are keybindings: there are stock items, and there are couple of places where modifiers and keyval from an event are checked directly.
Created attachment 110067 [details] [review] patch for non-bindings shortcuts
Created attachment 110068 [details] gtkrc with bindings
My keybinding theme does unbinding: bind "<meta>x" { "cut-clipboard" () } unbind "<ctrl>x" etc
Created attachment 110069 [details] gtkrc with bindings My bad. So, a patch and gtkrc. Should gtkrc go into gtkrc.c into the default gtkrc string?
Thanks! For the rc file part, I'd suggest to just install the file and set the key theme name on mac to that one. Regarding the mask, I think a better name would be *_COMMAND_MASK, or something similar, and document it as "the modifier that is normally used for menu shortcuts on the platform" and expose it so that apps can use it too. I guess it's a bit hackish, but the current hardcoding is also very hackish anyway... We need some feedback from non-mac gtk:ers too.
(In reply to comment #10) > Thanks! For the rc file part, I'd suggest to just install the file and set the > key theme name on mac to that one. Does "Mac" key theme sound good? > Regarding the mask, I think a better name would be *_COMMAND_MASK, or something > similar, That's "Control", no? Perhaps a better one would be some GTK_ACCEL_MOD_MASK. > and document it as "the modifier that is normally used for menu > shortcuts on the platform" and expose it so that apps can use it too. I guess > it's a bit hackish, but the current hardcoding is also very hackish anyway... > We need some feedback from non-mac gtk:ers too. Note that you also need a string, for accelerator strings - <Ctrl>a vs <Meta>a. Ideally you'd need a new design for accelerators stuff in Gtk. I mean, saving the world is a separate task, different from making Cmd-C copy text ;)
(In reply to comment #11) > (In reply to comment #10) > > Thanks! For the rc file part, I'd suggest to just install the file and set the > > key theme name on mac to that one. > > Does "Mac" key theme sound good? Sounds good to me (that's what I'm using in my simple copy/cut/paste theme). > > Regarding the mask, I think a better name would be *_COMMAND_MASK, or something > > similar, > > That's "Control", no? Perhaps a better one would be some GTK_ACCEL_MOD_MASK. I'm not sure I understand what do you mean by "that's control?". How about GTK_DEFAULT_ACCEL_MOD_MASK? Just "accel" is a bit too generic in my opinion, since any modifier is a potential accel mod.
Created attachment 110245 [details] [review] Single patch with key theme
Created attachment 110550 [details] [review] patch Updated patch, now with Alt-Left and Alt-Right in text widgets bound to Ctrl-Left and Ctrl-Right actions.
Ping! Is this ready to be committed?
I second that. Many applications now are trying to release for OS X using native gtk+ and having this in 2.18 would be a big help.
Looks ok to me.
looks good to me too, but does not go far enough IMHO. as mentioned on IRC with mitch and matthias, GTK should really provide abstracted modifier masks too. this patch fixes the builtin widgets but still doesn't provide any standard way for GTK applications (and it *is* a toolkit) to determine the right modifiers to be using given the platform. with this patch, GTK will get its own bindings correct, but applications will still end up using CONTROL, MOD1 etc with no standard platform-sensitive scheme. no reason not to commit, but i just wanted to make this note. in ardour, we have come up with the idea of 4 sets of modifier masks, called "primary", "secondary", "tertiary" and "level4" (couldn't think of a nice greek/latin prefix for "fourth" :). The application code uses these exclusively, not GDK_CONTROL_MASK etc. The modifiers are set at compile time, per platform. On linux, they are, in order: Control, Alt, Shift, Mod4+Super. On os x, they are Command, Alt, Shift, Control. this matches standard usage on that platform.
*** Bug 590355 has been marked as a duplicate of this bug. ***
*** Bug 585510 has been marked as a duplicate of this bug. ***
Comment on attachment 110550 [details] [review] patch commit 3c510f028f9a399c80851d2cb8c230e930abd4ff
(In reply to comment #21) > (From update of attachment 110550 [details] [review]) > commit 3c510f028f9a399c80851d2cb8c230e930abd4ff this commit seems to have gone awry - a jhbuild-driven checkout from git didn't find gtkrc.key.mac even though the other changes were preset in Makefile.am etc ... or maybe jhbuild messed up the checkout?
Hard for jhbuild to mess up the checkout. Anyway, http://git.gnome.org/cgit/gtk+/tree/gtk doesn't show gtkrc.key.mac either. Comparing http://bugzilla.gnome.org/attachment.cgi?id=110550 with http://git.gnome.org/cgit/gtk+/commit/?id=3c510f028f9a399c80851d2cb8c230e930abd4ff shows that the commit bears little resemblance to the submitted patch.
(In reply to comment #22) > (In reply to comment #21) > > (From update of attachment 110550 [details] [review] [details]) > > commit 3c510f028f9a399c80851d2cb8c230e930abd4ff > > this commit seems to have gone awry - a jhbuild-driven checkout from git didn't > find gtkrc.key.mac even though the other changes were preset in Makefile.am etc > ... or maybe jhbuild messed up the checkout? Sorry, my fault New commit with the missing file: http://git.gnome.org/cgit/gtk+/commit/?id=4ff709c24b8d4b3e26b3d513fde0676e9c43f897
Much better, thanks.
So, can this be closed now, or is it open for Paul's modifier masks?
(In reply to comment #26) > So, can this be closed now, or is it open for Paul's modifier masks? Yeah, I've open a new bug to request abstracted modifier masks here: bug #601863