Show a shortcut the way the keyboard shows it - #529
Merged
Conversation
The recorder displayed Ctrl+Oem7. Honest — that is what gets registered — but nobody pressed "Oem7", they pressed ². It now reads Ctrl+² on an AZERTY board and Ctrl+' on a US one. Only the display changes. A shortcut is stored, sent and registered as a position, because that is what RegisterHotKey takes and what makes a recorded shortcut mean the same physical key after a layout change. The character is looked up at display time with MapVirtualKey(VK_TO_CHAR), so switching layouts changes what is shown without invalidating anything. Falls back to the position name whenever there is no character to show — a key that prints nothing, a control character, a failed lookup. Never a blank button, never half-translated. Keys that already read as themselves (M, F12, Space, NumPad0) are not put through it at all. This does add a third table to keep in step: the virtual-key codes on the C# side must be the daemon's. Drift there would point the display and the registration at two different keys with nothing to notice — so they are asserted here as they already were in shortcut.rs. The display tests assert shape, not characters: Oem7 prints ² here and ' on the CI runner, so they pin that the result is either a single character or the position name.
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.
Follow-up to #528, which left the recorder displaying
Ctrl+Oem7. Honest — that is what gets registered — but nobody pressed "Oem7", they pressed².It now reads
Ctrl+²on an AZERTY board andCtrl+'on a US one.Only the display changes
A shortcut is stored, sent and registered as a position. That is what
RegisterHotKeytakes, and it is what makes a recorded shortcut mean the same physical key after a layout change. Nothing about that moves here.The character is looked up at display time with
MapVirtualKey(VK_TO_CHAR), so switching layouts changes what is shown without invalidating the setting, the wire, or the registration.It falls back to the position name whenever there is no character to show — a key that prints nothing, a control character, a lookup that fails. Never a blank button, never half-translated. Keys that already read as themselves (
M,F12,Space,NumPad0) are not put through it at all.The cost, stated
This adds a third table to keep in step: the virtual-key codes on the C# side have to be the daemon's. Drift there would point the display at one key and the registration at another, with nothing to notice — so they are asserted here as they already were in
shortcut.rs.The display tests assert shape rather than characters, since
Oem7prints²on the author's keyboard and'on the CI runner: the result must be either a single character or the position name.Tests
129 in the UI suite (was 113); 105 + 60 + 5 elsewhere, 56 Rust — all unchanged.