Keyman 15.0 beta
We are pleased to announce the release of Keyman 15 Beta. The most significant changes in version 15 are:
Android, iOS and Web
- Caps Lock Layer + double-tap gesture (#5988, #5989)
- Start of Sentence detection (#5963)
- Core-based debugger (#5425, #5448, #5513)
- Keyman Developer Server (#6033,#6034,#6035,#6036)
- Improved native-mode debugger (#5696, #5640, #5647)
- Web test no longer needs Developer tools for touch testing (#5723)
- U_xxxx_yyyy identifiers (#5894)
We have made many other smaller changes as well, which we have listed on the Keyman 15 home page.
Let us know what you think so we can make Keyman 15 a better product. If you run into a bug or issue, please report it here.
In order to help our developers replicate your issue, please include the following:
- the language you are working with
- the keyboard layout your are using
- the type of device
- version of the operating system
- version of the Keyman beta application or app
It seems keyboard authors need to update their keyboards to support casing. Right? I have two issues here.
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…)
“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.
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
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:
You would remove the line
store(&CasedKeys) [K_A] .. [K_Z] and instead implement the casing rules yourself, with virtual character keys instead of virtual keys.
I’ll see if I can reproduce this problem here, and if so, we’ll open an issue to track this.
I’m not sure I completely understand this – can you give some examples of what you mean?
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.
Can you share your keyboard with me (DM is fine)?
Ok. I have sent it your DM.
@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
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.
Is it possible that you have set “Next Layer” to “default”? If so, change it to “None”
In this case, this is interacting with the new
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:
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.)
Edit: here’s the separate fix: fix(web): bounding rect offset was incorrect by mcdurdin · Pull Request #6357 · keymanapp/keyman · GitHub
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
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
if(&layerChanged = "0") > use(detectStartOfSentence)
Now is the time to bed this down, in beta, before we go to 15.0-stable!
The “Next layer” property is already set to “None”.
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).
Noted. Just notify us when you’re done with the design. More grace.
Thank you for your patience!
The latest build of Keyman, 15.0.220-beta, includes the changes for
&oldLayer. See https://help.keyman.com/developer/language/guide/casing-support#toc-start-of-sentence-detection for details on how these work – the changes are minimal; in your case you probably only need to change from:
if(&layerChanged = '0') ...
if(&newLayer = '') ...
There is one outstanding issue on iOS (in-app keyboard only) which we will be working on, #6416 - switching keyboards does not trigger
newContext, but that should hopefully not impact you.
In KM 15.0.221, the situation is reversed. All other keys on caps layer output lowercase letters while ỌỌ̀Ộ N̄ CH SH M̀ now show in uppercase.