feat(windows): Change caps to work with common core processor#5803
feat(windows): Change caps to work with common core processor#5803
Conversation
User Test ResultsTest specification and instructions ✅ SUITE_CL: Caps Lock
✅ SUITE_OFF: CapsAlwaysOff
🟥 SUITE_SHIFT: CapsOnOnly/ShiftFreesCaps
|
User TestingSUITE_CL: Caps LockThe test keyboard layouts are found in the keyman repo at The test cases below expect the usage of the Prerequisites before each test
Test cases
SUITE_OFF: CapsAlwaysOffFor these tests, use a keyboard with the Any keyboard with that store set will work; if you don't have one at hand you can use the Note: When testing in a virtual machine, use an on-screen keyboard (in VirtualBox: Input/Keyboard/Soft Keyboard) and observe the caps lock indicator of the on-screen keyboard. Using the hardware keyboard might show side effects with caps lock. Prerequisites before each test
Test cases
SUITE_SHIFT: CapsOnOnly/ShiftFreesCapsFor these tests, use a keyboard with the Any keyboard with these stores set will work; if you don't have one at hand you can use the The shift_frees_caps.kmp keyboard will enable caps lock by pressing the Note: When testing in a virtual machine, use an on-screen keyboard (in VirtualBox: Input/Keyboard/Soft Keyboard) and observe the caps lock indicator of the on-screen keyboard. Using the hardware keyboard might show side effects with caps lock. Prerequisites before each test
Test cases
|
mcdurdin
left a comment
There was a problem hiding this comment.
This looks really clean. There's one functional change I think we need to make (!Updateable) which may have side-effects so will need testing. Apart from that LGTM.
| // We only want to process the Caps Lock key event once -- | ||
| // in the first pass (!Updateable). | ||
| if (Updateable){ | ||
| return TRUE; | ||
| } |
There was a problem hiding this comment.
We shouldn't be processing in the !Updateable pass -- this is essentially read-only.
Co-authored-by: Marc Durdin <marc@durdin.net>
I have done some testing this morning. Processing only on the Updatable pass doesn't work for |
mcdurdin
left a comment
There was a problem hiding this comment.
Oh my bad. I just looked at the code comment in the old Windows core and it was exactly the same -- doing this in the !Updateable pass. So clearly that works and has been the One True Method for all this time, so let's go with it!
LGTM
…caps-tests feat(windows): manual keyboard caps tests
The path to the keyboard packages for testing this PR doesn't exist, but there is something like this |
Yes this is correct and I have updated the test instructions |
SUITE_CL: Caps Lock
SUITE_OFF: CapsAlwaysOff
|
|
For TEST_CAPSONLY-5: FAILED I tested the team city build for this PR on windows "on the metal" machine (not a VM) and this test passes. The way the on-screen keyboard sends the shift events seems different. Visually you click shift once and an indicator goes on(green) then you press it again and the indicator goes amber, you have to press it a 3rd time to go off. @MakaraSok I just thought can check this with the old windows keyboard processor as a reference. To do this go into keyman configuration, select options on the left-hand side, down the bottom is |
|
Talking with @ermshiperete using the VM soft keyboard it does NOT actually send the Shift Shift Key Stroke through but rather will change the keys pressed for example if an a is pressed the soft keyboard itself will change that key to a A. This means we can't do Test TEST_CAPONLY-5 on a soft keyboard. I will still merge this PR as it passes when an actual shift stroke is sent through. |



The Keyman for Windows engine now sends through the Modifier key presses to the core processor so it could evaluate the key press against the keyboard rules for Caps. The Windows engine now to process the KM_KBP_IT_CAPSLOCK action and synthesizes key presses accordingly.
Fixes #5652