Reporting a bug I hit while running the test suite on a second Mac.
What happened
AppShortcuts.conflictWarnings decides whether two shortcuts clash by grouping them on their rendered display string:
displayToIDs[display, default: []].append(shortcut.id)
That string is produced by UCKeyTranslate against the active keyboard layout (AppShortcutOverride.currentLayoutCharacter). On some layouts two distinct bindings render to the same characters, so unrelated shortcuts get reported as conflicting — and which ones a user sees depends on their layout.
On the machine below, ⌥⌘F (Toggle Files Inspector) and ⌥⌘N (Toggle Notifications Inspector) render identically and Files is reported as "Conflicts with Toggle Notifications Inspector." ⌥⌘G (Toggle Pull Request Inspector) is unaffected, so it is not every key collapsing — consistent with kUCKeyTranslateNoDeadKeysBit yielding an empty string for both of those.
Steps to reproduce
Easiest signal is the existing test — no UI needed:
inspectorShortcutsHaveNoDefaultConflict() fails on the affected machine and passes on another, from identical source. In the app itself, Settings → Shortcuts shows the phantom warning on the inspector shortcuts.
What I expected
Conflicts to reflect the actual bindings, not how they happen to render on the current layout.
Environment
- Supacode
main @ 8829d6a (the code is unchanged since v0.10.8)
- macOS 26.4.1, Mac mini (Apple silicon)
- System locale
en_PL
- No input source is configured on that machine: neither
AppleSelectedInputSources nor AppleCurrentKeyboardLayoutInputSourceID exists in com.apple.HIToolbox. That looks like the trigger — with no resolvable layout, currentLayoutCharacter returns nothing for these keys and their displays collapse together.
- Reproduces both interactively and under a self-hosted CI agent
Suggested fix
Group on the key equivalent plus modifiers rather than the rendered display, and keep display for the system-reserved check and the settings UI, where the localised string is exactly what should be shown.
I have this written and make check passes against main. Happy to open the PR once this is marked ready, per CONTRIBUTING.
Reporting a bug I hit while running the test suite on a second Mac.
What happened
AppShortcuts.conflictWarningsdecides whether two shortcuts clash by grouping them on their rendereddisplaystring:That string is produced by
UCKeyTranslateagainst the active keyboard layout (AppShortcutOverride.currentLayoutCharacter). On some layouts two distinct bindings render to the same characters, so unrelated shortcuts get reported as conflicting — and which ones a user sees depends on their layout.On the machine below, ⌥⌘F (Toggle Files Inspector) and ⌥⌘N (Toggle Notifications Inspector) render identically and Files is reported as "Conflicts with Toggle Notifications Inspector." ⌥⌘G (Toggle Pull Request Inspector) is unaffected, so it is not every key collapsing — consistent with
kUCKeyTranslateNoDeadKeysBityielding an empty string for both of those.Steps to reproduce
Easiest signal is the existing test — no UI needed:
inspectorShortcutsHaveNoDefaultConflict()fails on the affected machine and passes on another, from identical source. In the app itself, Settings → Shortcuts shows the phantom warning on the inspector shortcuts.What I expected
Conflicts to reflect the actual bindings, not how they happen to render on the current layout.
Environment
main@ 8829d6a (the code is unchanged since v0.10.8)en_PLAppleSelectedInputSourcesnorAppleCurrentKeyboardLayoutInputSourceIDexists incom.apple.HIToolbox. That looks like the trigger — with no resolvable layout,currentLayoutCharacterreturns nothing for these keys and their displays collapse together.Suggested fix
Group on the key equivalent plus modifiers rather than the rendered display, and keep
displayfor the system-reserved check and the settings UI, where the localised string is exactly what should be shown.I have this written and
make checkpasses againstmain. Happy to open the PR once this is markedready, per CONTRIBUTING.