fix: uppercase characters when Option modifier is pressed#329
fix: uppercase characters when Option modifier is pressed#329akitchen merged 3 commits intokeycastr:mainfrom Hephaest:main
Conversation
When pressing Option+character (e.g., Option+L), the displayed keystroke was showing lowercase characters (⌥l) while Command+character correctly showed uppercase (⌘L). This was caused by the isCommand flag only checking for Control and Command modifiers, but not Option. The fix updates the condition to include the Option modifier flag, ensuring consistent behavior across all modifier keys.
|
Hi @akitchen Could you help review this PR? I think this will be important for users like me—today, many rely on Option + letter shortcuts, and I'm sure this fix will benefit countless KeyCastr lovers. 😊 |
|
Hey, thanks for opening a PR about this. There's a bit of context here. Originally this choice was intentional - command keystrokes (with Command or Control modifier) would always be capitalized, but non-command keystrokes would not. For a long while modified keys would be translated by a different mechanism which gave unexpected results for some option-modified keys which seemed like bugs. Fast forward to today and there's a pretty decent translation solution in place with an option to display modified keys or not, with a translation solution which works well for all locales I'm able to test. There are some open issues with complaints about modifier translation in other scripts or custom layouts but it's not clear that it's anything KeyCastr can solve for. Regardless, keys with the shift modifier are always translated (i.e. shifted), which could be considered a bug, while option-modified keys are not. I can understand that it looks strange. So I wonder (and wonder if @sdeken has thoughts here too) whether we should take this change and simply always capitalize modified keys, or go the other way and not display e.g. Shift-S with a capital S anymore unless the option to apply modifiers is enabled. Either way I think you should also update the unit tests for the event transformer, which aren't currently run by GitHub. This is also still a very legacy area of code I've been thinking about refactoring further, but haven't had much time for keycastr lately. I'm planning on trying to put out a release soon, so hopefully Stephen can chime in and we can consider what we want to do here. |
|
Hey @akitchen , Thanks for sharing the detailed context! I did feel there might be some reasons for the current strange behaviors, especially considering the wider audience. Per your suggestion, I’ve added unit tests to the PR (surprisingly, none existed before). I’m not yet fluent with the iOS testing framework, so I leaned on AI for guidance, but I also ran the tests locally and everything passes: ⬇️ I’m happy with whichever direction you and @sdeken decide to take—my local build already solves the issue on my end—and I’m excited to see where the project goes next. Thanks again! 😊 |
|
Thanks for generating some tests for this; what I had in mind was to update (or add) a couple cases to https://github.com/keycastr/keycastr/blob/main/keycastr/KCVisualizerTests/KCKeystrokeConversionTests.m |
Hey @akitchen Thanks for the hint! After reading the test case of 
All test cases have been passed ✅ and the demo has been update in the PR description ⬆️, feel free to check out 😃 |
Description
When pressing Option+character (e.g., Option+L), the displayed keystroke was showing lowercase characters (⌥l) while Command+character correctly showed uppercase (⌘L).
Screen.Recording.2025-06-27.at.13.30.05.mov
Changlog
The fix updates the condition to include the Option modifier flag, ensuring consistent behavior across all modifier keys.
Root Cause
This bug seems to be caused by the
isCommandflag only checking for Control and Command modifiers, but not Option.Demo
Screen.Recording.2025-06-29.at.12.03.27.mov