-
-
Notifications
You must be signed in to change notification settings - Fork 111
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix(mac): OSK layers displayed consistently for hardware and OSK modifiers #12829
Conversation
additional logic applied to keep two modifier types consistent with each other also lots of refactoring to keep naming clear Fixes: #12582
User Test ResultsTest specification and instructions
Test Artifacts
|
@SabineSIL I did some refactoring (mostly renaming) as part of this PR to more easily distinguish the difference between OSK modifiers and modifier keys on the physical keyboard. The actual changes in logic are limited. The most substantial is the replacement of Secondly, for all methods in |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm
A suggested change on if/else blocks in setPhysicalShiftState, setOskShiftState, setPhysicalOptionState, setOskOptionState, setPhysicalControlState, setOskControlState
if (state) { | ||
os_log_debug([KMELogs oskLog], "hardware shift key pressed"); | ||
[self displayKeyLabelsForLayer]; | ||
[self displaysShiftKeysAsPressed:YES]; | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
[self displayKeyLabelsForLayer];
occurs in the if and the else block, Can this be moved outside the if/else?
The same happens in functions: setOskShiftState, setPhysicalOptionState, setOskOptionState, setPhysicalControlState, setOskControlState
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was considering doing that for the three physical state changes -- the osk state changes are not a simple if/else -- but I am holding off for now. I am about to work on another PR where I may be refactoring this further. I'd like to move this logic elsewhere as it shouldn't be located in the view class.
Test ResultsI tested this issue with the attached "Keyman 18.0.160-aplha-local" build on macOS and am sharing my observations here.
|
Changes in this pull request will be available for download in Keyman version 18.0.161-alpha |
The correct layers of the keyboard are displayed whether layers are changed with the physical keyboard or by clicking a modifier on the OSK or a combination of the two.
Fixes: #12582
User Testing