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 530351 - Use standard mac shortcuts
Use standard mac shortcuts
Status: RESOLVED FIXED
Product: gtk+
Classification: Platform
Component: Backend: Quartz
2.18.x
Other Mac OS
: Normal normal
: ---
Assigned To: gtk-quartz maintainers
gtk-bugs
: 585510 590355 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2008-04-28 13:02 UTC by Yevgen Muntyan
Modified: 2009-11-14 01:27 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
patch (15.30 KB, patch)
2008-04-28 13:03 UTC, Yevgen Muntyan
none Details | Review
patch for non-bindings shortcuts (7.52 KB, patch)
2008-04-28 21:29 UTC, Yevgen Muntyan
none Details | Review
gtkrc with bindings (1.42 KB, text/plain)
2008-04-28 21:29 UTC, Yevgen Muntyan
  Details
gtkrc with bindings (1.80 KB, text/plain)
2008-04-28 21:48 UTC, Yevgen Muntyan
  Details
Single patch with key theme (12.22 KB, patch)
2008-05-01 20:59 UTC, Yevgen Muntyan
none Details | Review
patch (13.39 KB, patch)
2008-05-07 21:30 UTC, Yevgen Muntyan
committed Details | Review

Description Yevgen Muntyan 2008-04-28 13:02:37 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.
Comment 1 Yevgen Muntyan 2008-04-28 13:03:45 UTC
Created attachment 110036 [details] [review]
patch
Comment 2 Richard Hult 2008-04-28 15:13:32 UTC
Mac bindnings should not be done by patching the source but by providing a gtkrc.

Comment 3 Yevgen Muntyan 2008-04-28 21:05:34 UTC
(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.
Comment 4 Richard Hult 2008-04-28 21:14:39 UTC
The idea was of course that the keybinding theme would unbind the "linux" binding. Or do you mean that wouldn't work?

Comment 5 Yevgen Muntyan 2008-04-28 21:26:14 UTC
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.
Comment 6 Yevgen Muntyan 2008-04-28 21:29:06 UTC
Created attachment 110067 [details] [review]
patch for non-bindings shortcuts
Comment 7 Yevgen Muntyan 2008-04-28 21:29:48 UTC
Created attachment 110068 [details]
gtkrc with bindings
Comment 8 Richard Hult 2008-04-28 21:40:32 UTC
My keybinding theme does unbinding:

  bind "<meta>x" { "cut-clipboard" () }
  unbind "<ctrl>x"

etc

Comment 9 Yevgen Muntyan 2008-04-28 21:48:33 UTC
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?
Comment 10 Richard Hult 2008-04-29 08:39:33 UTC
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.
Comment 11 Yevgen Muntyan 2008-05-01 17:41:04 UTC
(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 ;)
Comment 12 Richard Hult 2008-05-01 20:40:58 UTC
(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.

Comment 13 Yevgen Muntyan 2008-05-01 20:59:48 UTC
Created attachment 110245 [details] [review]
Single patch with key theme
Comment 14 Yevgen Muntyan 2008-05-07 21:30:27 UTC
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.
Comment 15 jessevdk@gmail.com 2009-06-13 09:26:10 UTC
Ping! Is this ready to be committed?
Comment 16 Christian Hergert 2009-07-20 01:55:41 UTC
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.
Comment 17 Matthias Clasen 2009-07-20 03:31:51 UTC
Looks ok to me.
Comment 18 Paul Davis 2009-07-20 12:02:44 UTC
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.
Comment 19 Yoav HaCohen 2009-07-31 16:08:08 UTC
*** Bug 590355 has been marked as a duplicate of this bug. ***
Comment 20 Paolo Borelli 2009-08-01 17:08:46 UTC
*** Bug 585510 has been marked as a duplicate of this bug. ***
Comment 21 Javier Jardón (IRC: jjardon) 2009-10-25 23:03:33 UTC
Comment on attachment 110550 [details] [review]
patch

commit 3c510f028f9a399c80851d2cb8c230e930abd4ff
Comment 22 Paul Davis 2009-10-27 14:02:12 UTC
(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?
Comment 23 John Ralls 2009-10-27 18:25:51 UTC
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.
Comment 24 Javier Jardón (IRC: jjardon) 2009-10-27 23:56:59 UTC
(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
Comment 25 John Ralls 2009-10-28 00:23:12 UTC
Much better, thanks.
Comment 26 John Ralls 2009-11-13 21:10:49 UTC
So, can this be closed now, or is it open for Paul's modifier masks?
Comment 27 Javier Jardón (IRC: jjardon) 2009-11-14 01:27:14 UTC
(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