GTK: performable keys that map to menu accelerators always perform their action
#4522
Comments
|
This applies to macOS too. |
mitchellh
changed the title
performable keys that map to menu accelerators always perform their actionperformable keys that map to menu accelerators always perform their action
|
macOS resolution in #4591 |
Sorry for the vague title. This PR addresses multiple issues: 1. Fixes #4540 2. #4522 is fixed for macOS only 3. Fixes #4590 4. Fixes an untracked issue where `command+key` events will not send release events for Kitty keyboard protocol, something I only noticed while working on this. There are multiple components to this PR. ## Part 1: `App/Surface.keyEventIsBinding` This new API (also available in libghostty as `ghostty_surface_key_is_binding`) returns a boolean true if the given key event would match a binding trigger if it was the next key event sent. It does not process the binding now. This can be used by event handlers that intercept key events to determine if it should send the event to Ghostty. This helps resolve #4590 for us but is also part of all resolved issues. ## Part 2: macOS `performKeyEquivalent` changes macOS calls `performKeyEquivalent` for any key combination that may trigger a key equivalent. if this returns `true` then it is handled and macOS ceases processing the event. We were already using this to intercept things like `Ctrl+/` which triggers a context menu in macOS Sequoia. But we now expand this to intercept all events to check for bindings. This lets us fix #4590. Additionally, it's been changed to special case `cmd+period`. I'm sure more need to be added. ## Part 3: NSEvent local listener for command keyUp events macOS simply doesn't send `keyUp` events for key events with command pressed. The only way to work around this is to register an `NSEvent` local listener. We now do this. This fixes the untracked issue noted above.
|
Marked as Linux since macOS is now fixed. |
mitchellh
changed the title
performable keys that map to menu accelerators always perform their actionperformable keys that map to menu accelerators always perform their action
|
This is actually a non-issue on GTK because the surface gets the key events first and only surface events are performable. |
|
Actually this is an issue on GTK. |
|
For information, it is apparently possible to work around this issue on Linux by adding a second keybinding for copy_to_clipboard like the following that I have in my config at the moment: So if there is a second keybinding for copy_to_clipboard that does not include the performable part, it works as intended (at least when it is configured exactly as the above) |
|
I have to correct what I said in my last post above. It seemed to me at first like it was possible to work around this issue by adding a second keybinding for It seems like it's rather that if I add Sorry for the confusion. |
When a keybinding is available as a menu item, we set the keybinding as that menu items accelerator. When that is pressed, we go directly through the
performBindingmachinery. Unfortunately, since this happens before reaching the surface, we never callkeyCallbackand get all the input method inputs for this.We need to somehow hopefully tell GTK when an action is not performed that we want it to fall through to the normal input event propagation stack.
The text was updated successfully, but these errors were encountered: