macOS: Shortcuts are broken on "Dvorak-Qwerty ⌘" layout

[Viknet]

"Dvorak-Qwerty ⌘" transmorphic layout uses the Dvorak layout for unmodified keystrokes, but unlike the “normal” Dvorak layout, it actually retains the QWERTY layout for keys when pressed in combination with the ⌘ modifier.
For example: if i press key "v" on a keyboard, letter "k" will print out. But if I hold ⌘ and press key "v", it should activate "⌘+v" shortcut and do paste from clipboard.

After recent update to version 1.1.0 (build 9283, commit facda0c3) shortcuts with ⌘ modifier behave like it's regular Dvorak layout.
Now when I hold ⌘ and press key "v" it activates "⌘+k" shortcut.

[tulgeywood]

Yup, I'm seeing the same behavior. I wonder if it has something to do with the Performable Keybindings addition

[donmccurdy]

Running into the same thing. A few examples:

• ⌘+v should paste, instead clears output
• ⌘+w should close pane, instead opens preferences
• ⌘+k should clear output, instead opens a new pane
• ⌘+, should open preferences, instead closes pane

In each example above, I'm describing the physical location of the keypress on a QWERTY layout. This can be tested on any macOS device, with a standard QWERTY physical keyboard. All that's necessary is to switch the input source to "Dvorak-Qwerty ⌘" under the macOS keyboard settings. When ⌘ is pressed, these keys should not be remapped to Dvorak by the Dvorak-Qwerty ⌘ layout, so Ghostty remapping them is inconsistent with other applications on macOS. I'm testing with macOS 15.2, Ghostty 1.1.0 Build 9283. I think this must have broken recently.

[jabwd]

This seems to be related to the new key-binds that have been added recently, where these take priority over the regular shortcuts of macOS, in particular:

if let surface, ghostty_surface_key_is_binding( surface, event.ghosttyKeyEvent(GHOSTTY_ACTION_PRESS)) { self.keyDown(with: event) return true }

Found in SurfaceView_Appkit.swift. Related commit would be: 140ac93

I'm not entirely sure what a good fix is here, as bricking key-binds isn't very helpful either. I think there should be some more logic where if a key-bind is not defined by the user it should simply not handle it this way.

[somersf]

Similar case here, where I had keyboard shortcuts set up via macOS Settings / Keyboard Shortcuts / App Shortcuts to map keys to menu item names. These were working fine until I updated to Ghostty 1.1.0

Examples (I map those key sequences to whatever is the equivalent, for multiple apps):

• Show Previous Tab: OPTION CMD <-
• Show Next Tab: OPTION CMD ->

With 1.1.0, the keyboard shortcuts are shown next to the menu item in ghostty. However, the key sequences no longer activate the menu items.

Well... once, ghostty 1.1.0 showed OPTION CMD (with no l/r) beside both menu items.

[tulgeywood]

This is still an issue in 1.1.2