Re: [gtk-osx-users] global menu (with quartz accelerators) precedence over widget key bindings

[John Ralls <jralls ceridwen us>]

On Jan 9, 2012, at 5:30 AM, Jesse van den Kieboom wrote:

> When enabling quartz accelerators, the menu actions have priority over widget keybindings (since the menu accelerators are activated from the gdk event filter). However, normally in gtk+ the widget key bindings have priority over the menu of the window. I understand that in OS X, the menu is working slightly different and that the menu's sensitivity is based on the widget and which actions apply on that widget. However, I think it would be more consistent with the application currently to have keybindings activate prior to the menu. Would this be possible (or is it maybe better in this case not to use the quartz accelerators?) 

I'm leaning towards it's better not to use the quartz accelerators, though that messes with the "Quit" handling because the quit menu item is presently provided by Quartz... so it goes to the NSApplicationDelegate stuff. If you have quartz accelerators disabled, then cmd-Q goes to the (hidden) Gtk menu item and doesn't go through NSApplicationDelegate. It's pretty easy to fix the main menu item, but the dock menu and "shutdown" signals from Finder are a bit harder.

I haven't tested it, but I think that even on a native Cocoa app a widget keybinding would override a menu accelerator, provided that the widget in question had focus and so was first in the NSResponder chain, or that the NSWindow parent of the widget had a handler that forwarded the event to the widget. I don't offhand see a good way to replicate that with Quartz handlers.

Regards,
John Ralls