Disable or change local keyboard shortcuts on OS X when command/control keys are swapped

[jasom]

The Xpra client registers a few keyboard shortcuts (e.g. ⌘Q ⌘H). These are problematic if the swap command/control keys feature is in use, as there is now no way to send ^Q or ^H to the server.

[Antoine Martin]

(fixing formatting)

Likely to be related or similar to #708.

[Antoine Martin]

Some links:

• ​Mac keyboard shortcuts
• ​Intercept/Disable keyboard shortcuts (ex. CMD+q) - looks like we would have to set an event tap and return NULL when we intercept the key, no idea about injecting another one... or even if we should.
• ​accelerator problem with GtkOSXApplication discusses key shortcuts handled by gtk osx.
• ​gtk.AccelGroup
• ​global menu (with quartz accelerators) precedence over widget key bindings : 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.
• ​gtk-mac-menu.c key_press_event method seems to indicate that the event is handled in this order: text / editable widget with focus (if any), menu event, window key (only for control or mod1..), window focus widgets, window key again (but not for control or mod1 this time!).

So judging by the links above, I think we would need to patch gtk-osx-integration to NOT create the default menu entries, then we could add our own and register the correct accelerators for them.

Too much work for little benefit: if someone else is interested, there should be enough information here to have a go.

[migration script]

this ticket has been moved to: ​https://github.com/Xpra-org/xpra/issues/906