GNOME Bugzilla – Bug 773832
System keybindings get eaten
Last modified: 2018-04-15 00:17:28 UTC
Created attachment 338955 [details] [review] Let global keyboard shortcuts pass through I meant to try to push these patches upstream and I kind of forgot about them, then Kris found them in my github so I'm embarrassed that I haven't tried to contribute them yet. :) This tries to solve issues where some global keyboard shortcuts get eaten and don't pass through to the system. For example, Ctrl-F2 should focus the global menu. These patches are against gtk 2.x but may be applicable to gtk3. There is still an issue that I don't know how to solve properly, so I'll document that here in case someone else has an idea. The issue is that certain keyboard shortcuts seem to have an "opposite" shortcut that is inferred by the system and isn't explicitly defined. For example, window-cycling is a shortcut that defaults to Cmd-`. But users can also reverse-window-cycle using Cmd-Shift-` and this is not in the list of shortcuts. So these patches will not pass that through to the system.
Created attachment 338956 [details] [review] Don't call CopySymbolicHotKeys() so much
Thanks for filing! The second patch is important because of performance, but also because it fixes a memleak. It would be good if we could also add a listener for some "system shortcuts have been modified" notification, such that we can update the symbolic hotkey cache in GDK. Although I don't know whether such notification exists -- I couldn't find it so quickly. (In reply to Cody Russell from comment #0) > There is still an issue that I don't know how to solve properly, so I'll > document that here in case someone else has an idea. The issue is that > certain keyboard shortcuts seem to have an "opposite" shortcut that is > inferred by the system and isn't explicitly defined. For example, > window-cycling is a shortcut that defaults to Cmd-`. But users can also > reverse-window-cycle using Cmd-Shift-` and this is not in the list of > shortcuts. So these patches will not pass that through to the system. Tricky one. We could pass "+shift" versions of all registered shortcuts to the system, but there's of course a chance that these shortcuts are registered within the GTK+ application. Another idea is to locate and read the configuration/preferences file where shortcuts are stored, in an attempt to also get access to the name of the shortcut. But that also has it's own problems, such as not being future-proof and bypassing the API. I wonder how Cocoa handles this internally. Does it unconditionally first pass shortcuts to the system, and when not handled try to handle it within the application? Or does it first try to handle a shortcut within the application and when not handled pass it through to the system?
*** Bug 772680 has been marked as a duplicate of this bug. ***
> Another idea is to locate and read the configuration/preferences file where shortcuts are stored, in an attempt to also get access to the name of the shortcut. But that also has it's own problems, such as not being future-proof and bypassing the API. I could investigate this. It looks like they're stored in ~/Library/Preferences/com.apple.symbolichotkeys.plist > It would be good if we could also add a listener for some "system shortcuts have been modified" notification, such that we can update the symbolic hotkey cache in GDK. Although I don't know whether such notification exists -- I couldn't find it so quickly. I did a quick search and found someone on StackOverflow asking for this very thing. He/she tried to listen to NSNotificationCenter and NSDistributedNotificationCenter for global events to see if anything was fired, and it wasn't. The only other idea I can think of off the top of my head is that we could track the modification time of ~/Library/Preferences/com.apple.symbolichotkeys.plist and re-check this occasionally, maybe when NSApplication becomes active. If it's changed then we either re-CopySymbolicHotKeys() or re-parse the plist file. I know, I know.. kind of gross. :)
*** Bug 686164 has been marked as a duplicate of this bug. ***
We're moving to gitlab! As part of this move, we are moving bugs to NEEDINFO if they haven't seen activity in more than a year. If this issue is still important to you and still relevant with GTK+ 3.22 or master, please reopen it and we will migrate it to gitlab.
As announced a while ago, we are migrating to gitlab, and bugs that haven't seen activity in the last year or so will be not be migrated, but closed out in bugzilla. If this bug is still relevant to you, you can open a new issue describing the symptoms and how to reproduce it with gtk 3.22.x or master in gitlab: https://gitlab.gnome.org/GNOME/gtk/issues/new