Implement predictable behavior when clicking on a modifier key on the OSK and pressing the corresponding physical key.
After our design discussion, we agreed to the following:
#
OSK State
User Action
Expected Result
1
Open to default layer
A OSK modifier key is clicked with the mouse
The modifier key toggles state between selected or unselected and displays the corresponding layer of characters for each key on the keyboard.
2
Open to default layer
An OSK character key is clicked with the mouse
The key's character is output to the active client application.
3
Open with the shift layer selected and the SIL Euro Latin keyboard active
The user presses the 'S' key on the physical keyboard.
\=> capital 'S' OSK remains in the shift Layer
4
Open with the shift layer selected and the SIL Euro Latin keyboard active
The user holds down the shift key and presses the 'S' key on the physical keyboard, then releases the shift key.
\=> capital 'S' OSK returns to the default layer
5
Open with the shift layer selected and the Khmer Angkor keyboard active
The user holds down the option/alt key and presses the 'S' key on the physical keyboard, then releases option/alt key.
\=> ᧭ (RAlt+Shift+S) OSK returns to the shift layer
6
Open with the default layer selected and the SIL Euro Latin keyboard active
The user presses and releases the shift key on the physical keyboard.
OSK momentarily shows the shift layer, then returns to the default layer
7
Open with the default layer selected and the SIL Euro Latin keyboard active
The user presses and holds the shift key on the physical keyboard and then presses the 'S' key on the physical keyboard.
OSK momentarily shows the shift layer, \=> capital S, then returns to the default layer
8
Open with the default layer selected and the SIL Euro Latin keyboard active
The user presses the Caps Lock key.
Keyman shrugs (.kvk does not support Caps Lock yet) TODO: open a feature issue Future: show the Caps Lock layer Q: what happens to Shift state? Q: what about Shift Lock?
9
Open with the shift layer selected
The user closes the OSK and then opens it again.
OSK is reset to the current state of the hardware modifiers
Also see comments by @mcdurdin in #12556:
Pressing any modifier key on the hardware keyboard should reset all the OSK-selected modifier keys. This is the behaviour we settled on in Keyman for Windows, and it seems to be the most reliable option. (Testing right now, I am not sure if that is happening on Windows?)
Closing the OSK should reset the modifier state to default
The modifier state on the OSK should affect the hardware keys typed. Right now they seem completely independent.
Implement predictable behavior when clicking on a modifier key on the OSK and pressing the corresponding physical key.
After our design discussion, we agreed to the following:
Also see comments by @mcdurdin in #12556: