You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Numpad keys and GLFW bracket/grave names never match across frameworks: Ctrl+Keypad1 (ImGui), Ctrl+KP_1 (GLFW) and Ctrl+NumPad1 (WinForms/browser) are three different chords #244
Note.CanonicalizeKey (Keybinding/Models/MusicalTypes.cs:72-146, main @ 842853f) folds each framework's names for modifiers, main-row digits, navigation keys and (since #235) GLFW's multi-word names like PAGE_UP. The numpad keys and several other GLFW names were left out, so the same physical key gets a different canonical name depending on which host produced it. The comments at lines 74-75 and 107 deliberately keep numpad keys distinct from the main row — that part is right — but nothing folds the numpad's own names into one.
Repro (net10.0)
voidS(stringa,stringb){Chordx=Chord.Parse(a),y=Chord.Parse(b);Console.WriteLine($"{x} vs {y}{x.Equals(y)}");}S("LeftCtrl+Keypad1","Ctrl+NumPad1");// ImGui/Silk.NET vs WinForms/WPF/browserS("LEFT_CONTROL+KP_1","Ctrl+NumPad1");// GLFWS("LeftCtrl+KeypadAdd","Ctrl+Add");S("LEFT_CONTROL+KP_ENTER","Ctrl+KeypadEnter");S("LEFT_CONTROL+LEFT_BRACKET","Ctrl+LeftBracket");S("LEFT_CONTROL+GRAVE_ACCENT","Ctrl+GraveAccent");S("LEFT_CONTROL+PAGE_UP","Ctrl+PageUp");// control, fixed by #235
Output:
Ctrl+KEYPAD1 vs Ctrl+NUMPAD1 False
Ctrl+KP_1 vs Ctrl+NUMPAD1 False
Ctrl+KEYPADADD vs Ctrl+ADD False
Ctrl+KP_ENTER vs Ctrl+KEYPADENTER False
Ctrl+LEFT_BRACKET vs Ctrl+LEFTBRACKET False
Ctrl+GRAVE_ACCENT vs Ctrl+GRAVEACCENT False
Ctrl+PAGEUP vs Ctrl+PAGEUP True
Why it matters
A binding stored as Ctrl+NumPad1 from a WinForms/WPF/browser front end never fires from an ImGui/Silk.NET host (Keypad1) or a GLFW host (KP_1), and the UI shows raw names like KP_1 and LEFT_BRACKET. That is the cross-framework mismatch #205/#224/#235 fixed for other keys. Not covered by #197 (numpad vs main row) or #218 (browser KeyS/Digit1).
Suggested fix
Fold every framework's name for one numpad key to a single canonical name, still separate from the main row:
KEYPAD<x> and KP_<x> → NUMPAD<x>, for digits and ADD, SUBTRACT, MULTIPLY, DIVIDE, DECIMAL, ENTER, EQUAL.
Bare WinForms ADD/SUBTRACT/MULTIPLY/DIVIDE/DECIMAL → NUMPAD<op>.
Notes: the folding of bare WinForms ADD/SUBTRACT/… to NUMPAD<op> is the one behaviour change to look at closely: confirm no other host uses those bare names for main-row keys before mapping them.
Activity
matt-edmondson commentedon Nov 11, 2026
Triage
ControlLeft+Cnever equalsCtrl+Cand displays asC+CONTROLLEFT#205, ImGui key names aren't canonicalized:LeftCtrl+Key1shows asCtrl+KEY1andModCtrl+SasMODCTRL+S, so neither equalsCtrl+1/Ctrl+S#224 and Fold ImGui's Key0-Key9 and Mod flags, and GLFW's multi-word key names [patch] #235 fixed for other keys. It's limited to those keys.Keybinding/Models/MusicalTypes.csNote.CanonicalizeKey, plusKeyAliasEquivalenceTests.KeyboardEvent.code/ Silk.NET way aren't canonicalized:ControlLeft+KeySshows asCtrl+KEYSand never equalsCtrl+S#218 (browserKeyS/Digit1) are distinct, as the issue notes.KeyboardEvent.code/ Silk.NET way aren't canonicalized:ControlLeft+KeySshows asCtrl+KEYSand never equalsCtrl+S#218) edits the sameCanonicalizeKeytable, so expect a merge conflict. Land Fold browser and Silk.NET letter and digit key names into the plain key [patch] #219 first, or fold this into it. Bump System.Text.Json from 10.0.14 to 11.0.0 #241 is a dependency bump.Notes: the folding of bare WinForms
ADD/SUBTRACT/… toNUMPAD<op>is the one behaviour change to look at closely: confirm no other host uses those bare names for main-row keys before mapping them.Generated by Claude Code