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
This was referenced Jan 3, 2025
|
macOS resolution in #4591 |
mitchellh
added a commit
that referenced
this issue
Jan 4, 2025
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. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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: