It seems keyboard authors need to update their keyboards to support casing. Right? I have two issues here.
First,
Says:
15.0 has added “support for U_xxxx_yyyy_… identifiers so you can emit more than a single Unicode character with touch keys without additional kmn code (#5894)”
But when I try to compile, it says the key with U_xxxx_yyyy_… has invalid identifiers (where xxxx_yyyy are the Unicode hex values…)
Also, https://help.keyman.com/developer/language/reference/casedkeys
Says:
“This feature [i.e. &CasedKeys] is not compatible with mnemonic layouts, and the keys defined in the &CasedKeys store must be the unshifted base keys as found on a US English keyboard, …”
Which line of code can I safely remove from this worked example (Casing support) so it works on my mnemonic keyboard and make the Caps Lock Layer + double-tap gesture and Start of Sentence detection work? Right now, the key output is different from what is printed on the keys and double-tap doesn’t work.
Language: Obolo
Keyboard layout: Obolo Chwerty
Type of device: Laptop
Versrion of operating system: Windows 10
Version of the Keyman beta application or app: Developer 15.0.206
Update:
The double-tap gesture and start of sentence detection works on physical Android device but not in the debugger. If I use CAPS and NCAPS, instead of &CasedKeys, the key output on Android corresponds to the keycap except for the new “caps” layer.
Correct. We have a policy of not changing behaviour for existing keyboards (apart from straightforward bug fixes). This gives keyboard authors the assurance that their keyboards will keep working as they designed them, but the downside of potentially more work to access new functionality.
You’ll need to update your keyboard file version to 15.0: store(&VERSION) "15.0".
The output of the keys on caps layer are all in lower case by default. I had to define the output for each key in the layout tab before they show in uppercase. Despite defining the keys, these: Ọ N̄ CH SH M̀ Ọ̀ (on caps layer) continue to show in lower case.
What to do.
@katelem, thank you for your feedback on this. I’ve got two pull requests open which address the problems I reproduced as a result of your excellent report. These are undergoing testing now and should hopefully land in the next few days:
There are some issues in your keyboard with inconsistent use of CAPS and NCAPS. The first pull request above will make it much easier to spot the consistency issues because the compiler will now report on all of them. I have corrected the source myself and tested it along with the fixes in #6347 above, and as far as I can tell, it all works correctly with those fixes. Here’s the corrected version, which I have included as part of a test suite for verifying the caps lock code now – always good to have real keyboards for verification!
How do I tell the deadkey on shift layer to not switch the layer when pressed. On this keyboard, the layer should only be switched by a key that has output. If the deadkey switches layer, then it has no opportunity to do it’s work of modifying the output of the keys on that layer.
The layer switch is happening because your postKeystroke processing group is telling the keyboard to drop back to the default layer. The best way to avoid this is to add a rule telling the processor to skip the layer switch in the postKeystroke processing group:
group(PostKeystroke) readonly
dk(2) > context c stops T_ENG from dropping back to default layer
(Note: there is a separate bug fix for the web debugger coming shortly fixing a situation where the bottom row of the simulated touch layout was not interacting correctly with the mouse.)
Here’s a question for you @katelem (and anyone else who wants to chime in!).
As of 15.0.210-beta, the &layerChanged store will be set to '1' if a layer is changed during a keystroke, either through the “next layer” property of the touched key, or if the keyboard calls the layer() statement. However, there is a nuance here. If the keyboard sets the “next layer” property to the same layer as it is already in (as opposed to “(none)”), then &layerChanged will be '0', because the layer has not changed. (Same thing applies to the layer() statement.)
But might it be better to treat this as a layer change, from the perspective of the &layerChanged store, even though the change is just to switch to the same layer? That would mean that in @katelem’s example above, he could set shift+T_ENG's next layer to shift, and that would be enough to prevent the layer switching automatically on that key, because of the following rule in his postContext group:
We have agreed to change the meaning of &layerChanged in 15.0-beta; please see #6364 for details.
I will be working on this as soon as possible in the beta cycle; I apologise for the movement in design, but hope that the outcome will be worth it. (It will require a 1 minute update to the keyboard source).
