Record and send printable keys by character, resolved against the active keyboard layout - #21
Merged
Merged
Conversation
…e active layout Mappings stored a physical key code, and recording used a QWERTY table keyed by key code, so on Dvorak (or any non-QWERTY layout) both halves were wrong: pressing the key that types "x" was recorded as "b", and a mapping recorded as Cmd+X on QWERTY sent Cmd+Q. Fixes the layout half of #10. - KeyboardLayout resolves a printable character to the key (and whether Shift is needed) on the current input source via UCKeyTranslate, cached per source. - canonicalKeyString records printable keys by the character produced; special keys (Return, arrows, F-keys) still use the key-code table. - ButtonMapper resolves single-character keys through KeyboardLayout at send time and adds Shift when the layout requires it (digits on AZERTY), falling back to the recorded key code or the static table. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
primaryKeyNames is built from a dictionary, so "left" vs "left arrow" is nondeterministic. Assert the identifier resolves back to the key code instead. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
DParent10
force-pushed
the
fix/layout-aware-keys
branch
from
September 17, 2026 15:49
bd2f5e1 to
3a38ee7
Compare
This was referenced Sep 17, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What does this PR do?
Fixes the keyboard-layout half of #10 ("cut becomes quit on Dvorak").
Mappings stored a physical key code and recording used a QWERTY table keyed by key code, so on any non-QWERTY layout both halves were wrong: pressing the key that types
xon Dvorak was recorded asb, and a mapping recorded as Cmd+X on QWERTY sent Cmd+Q on Dvorak.KeyboardLayoutresolves a printable character to the key that produces it on the current input source (TISCopyCurrentKeyboardLayoutInputSource+UCKeyTranslate), including whether Shift is needed (digits on AZERTY). Cached per input source ID, rebuilt on layout change.KeyStroke.canonicalKeyStringnow records printable keys by the character produced. Special keys (Return, arrows, F-keys, Delete…) still come from the key-code table; their characters are controls or private-use code points.ButtonMapperresolves single-character keys throughKeyboardLayoutat send time and unions any required Shift into the event flags; falls back to the recorded key code, then the static table. Modifier-only keys and special keys are unaffected.Existing profiles keep working: a stored
"x"withkeyCode 7now resolves by the character first, so it types x on every layout.Testing
Unit tests added (
KeyboardLayoutTests): printable classification, capture preferring the character, and a live resolution on the current layout. Hardware check pending on Dvorak: existing Cmd+X mapping cuts rather than quits; recording a key while on Dvorak stores the right letter.🤖 Generated with Claude Code