Fix numpad vs non-numpad key ambiguity in shortcut binding#10576
Draft
ivandrofly wants to merge 1 commit intoSubtitleEdit:mainfrom
Draft
Fix numpad vs non-numpad key ambiguity in shortcut binding#10576ivandrofly wants to merge 1 commit intoSubtitleEdit:mainfrom
ivandrofly wants to merge 1 commit intoSubtitleEdit:mainfrom
Conversation
Previously, Avalonia's logical Key enum could not distinguish between numpad keys (with NumLock off) and their non-numpad counterparts. For example, pressing NumPad7 with NumLock off would produce Key.Home — identical to the regular Home key — making it impossible to bind different shortcuts to the two keys. Root cause: Avalonia's Key enum represents *logical* keys. When NumLock is off, numpad 7 fires Key.Home, numpad 1 fires Key.End, numpad 0 fires Key.Insert, NumPadDecimal fires Key.Delete, etc. The logical key alone carries no information about whether the key originated from the numpad. Fix: Use KeyEventArgs.PhysicalKey, which reflects the actual hardware key regardless of NumLock state. All numpad physical keys in Avalonia are named with the "NumPad" prefix (NumPad0–NumPad9, NumPadDecimal, etc.), while their logical counterparts are not (Home, End, Insert, Delete, etc.). The new GetEffectiveKeyName() helper returns the PhysicalKey name when the physical key is a numpad key, and the logical Key name otherwise. Concretely: - Regular Home: PhysicalKey.Home → "Home" - NumPad7 (NumLock ON): PhysicalKey.NumPad7 → "NumPad7" - NumPad7 (NumLock OFF): PhysicalKey.NumPad7 → "NumPad7" ← was "Home" Changes: - ShortcutManager: added GetEffectiveKeyName(Key, PhysicalKey) static helper and a parallel _activeEffectiveNames: HashSet<string> that tracks pressed keys using the physical override for numpad. The existing _activeKeys: HashSet<Key> is preserved unchanged so callers that rely on the logical Key enum (e.g. AllowedSingleKeyShortcuts filtering, GetActiveKeys().Count checks) continue to work. The shortcut hash lookup in CheckShortcuts now iterates _activeEffectiveNames instead of _activeKeys. - GetKeyViewModel: when the user presses a key to record a shortcut binding, the stored key name is now derived via GetEffectiveKeyName() so that numpad 7 (either NumLock state) is recorded as "NumPad7" rather than "Home", matching what CheckShortcuts will see at runtime. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Member
Author
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.
Summary
Key.Home) were indistinguishable from their non-numpad counterparts, making it impossible to bind different shortcuts to the two keysGetEffectiveKeyName(Key, PhysicalKey)helper inShortcutManagerthat returns thePhysicalKeyname when the physical key is a numpad key (all Avalonia numpad physical keys are prefixed with"NumPad"), falling back to the logicalKeyname otherwiseShortcutManagernow tracks a parallel_activeEffectiveNames: HashSet<string>using the physical override; shortcut hash lookup inCheckShortcutsiterates this set instead of_activeKeys, while_activeKeysis preserved so existing callers (count checks,AllowedSingleKeyShortcutsfiltering) are unaffectedGetKeyViewModelusesGetEffectiveKeyName()when recording a key press so that numpad 7 (either NumLock state) is saved as"NumPad7"rather than"Home", matching whatCheckShortcutssees at runtimeTest plan
HomeNumPad7(notHome)NumPad7Homeand a different shortcut toNumPad7; confirm each fires its own action independently🤖 Generated with Claude Code