Skip to content

Resolve Latin keys through real keyboard layouts - #1965

Open
raphamorim wants to merge 1 commit into
non-latin-layoutsfrom
latin-layout-resolution
Open

raphamorim wants to merge 1 commit into
non-latin-layoutsfrom
latin-layout-resolution

Conversation

@raphamorim

Copy link
Copy Markdown
Owner

Stacked on #1964. That PR matches shortcuts on non-Latin layouts by mapping the physical key to its standard PC-101 position, which is kitty's model and works for any layout, but it cannot describe layouts whose Latin group is not PC-101 (Dvorak alongside Cyrillic, AZERTY alongside Arabic, Colemak, ...).

This PR adds the mechanism ghostty effectively relies on: resolving the key through the user's real keyboard layouts, at the window layer where the layout information lives.

rio-window

New KeyEventExtModifierSupplement::base_layout_key() returning the key resolved against a Latin (ASCII-capable) layout, ignoring modifiers:

  • Linux (Wayland and X11): scan the xkb layout groups configured for the key, active group first, and take the first group whose level-0 keysym is an ASCII character. This mirrors xkb's own group fallback for shortcuts, the same behavior GTK apps get (GDK feeds it to ghostty, which is how ghostty shortcuts work on Cyrillic).
  • macOS: translate the scancode through TISCopyCurrentASCIICapableKeyboardLayoutInputSource with UCKeyTranslate, the same resolution AppKit applies to key equivalents. Skipped when the active layout already produced ASCII.
  • Windows and Orbital: None for now. A follow-up can use ToUnicodeEx against a US HKL; until then the frontend falls back to the PC-101 table, which matches Windows scancode positions anyway.

rioterm

base_layout_fallback_key now prefers the platform's resolution and keeps the PC-101 table as the fallback (Windows, resolution failure). The kitty protocol's alternate-keys field intentionally stays on the PC-101 table, since the spec defines the base layout key as the key at that position in the standard PC-101 layout.

All gating from #1964 is unchanged: command modifier required, layout-character bindings take precedence, Windows AltGr chords that typed text are never rewritten.

Testing

  • Unit tests for the resolution preference and fallback (Dvorak-style divergence, non-ASCII resolution rejected).
  • All 226 rioterm tests and rio-window lib tests pass on macOS; fmt clean.
  • Linux xkb path compiles on CI (macOS hosts cannot cross-check it: build.rs generates dispatch bindings from the host OS, a pre-existing issue).
  • Needs manual verification on a Cyrillic+Dvorak or similar multi-group xkb setup.

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant