Keyman 15 Beta Feedback

More grace to the Keyman team.
I will like you to fix 6 other issues:

  1. Shift key colour: differentiate between the shift layer and the caps lock layer.
  2. Activate the “find and replace” option in Wordlist tap of lexical model projects. It’s there but not working.
  3. Lexical model should suggest words according to the current layer even before the user starts typing. For example, when kb is in default layer, all suggestions should be in lower case; in shift layer, all suggestions should be in Initial Caps; in caps layer, all suggestions should be in ALL CAPS.
  4. When the Enter key is pressed, keyboard should switch to “shift” layer.
  5. On mobile devices, I want the keyboard to stay in the symbols layer until the user changes it. [I use “alt” as symbols layer]. In GBoard I can pick as many symbols as I want in the symbol layer then as soon as I tap space bar, it switches to default layer.
  6. Consistency in the output when I accept a suggestion from the lexical model.
    Current Situation:
    As I Start Typing: when I accept a suggestion, the keyboard automatically adds a space after the suggested word.
    After Typing For Some Time: when I accept a suggestion, the keyboard doesn’t add a space after the suggested word. I have to tap the space bar twice to insert a single space.
    The Effect: It is a pain to keep tapping space bar twice to insert a single space, and if I forget to tap twice, the words are joined together. And then whether the keyboard will automatically add space or not is unpredictable, so I have to be on the lookout while typing.

But In GBoard: when I accept a suggestion, the keyboard doesn’t add space after the word. Then if I type another letter of the alphabet, the keyboard automatically adds space to the suggested word before printing the new letter. But if after accepting the suggestion, I type a punctuation mark, the keyboard places the mark next to the suggested word without adding space.

It seems #4 can be fixed by keyboard authors. But how to do it.
I also think #5 can be fixed by keyboard authors if Keyman will give them the power to decide whether a layer (apart from "shift layer) should switch or not switch.

I think this is related to some inconsistent use of CAPS and NCAPS in your keyboard. When testing with the version I tweaked to resolve this, I did not experience any issues. Can you compare what you have with that keyboard?

1 Like

Thank you for the detailed feedback! Some of these things you can resolve; the others I have taken note of.

More control over theming is coming in 17.0 according to our Roadmap, later this year. For now, the best answer is to use CSS in your keyboard (you may want to differentiate between iOS and Android):

.ios .kmw-keyboard-obolo_chwerty #caps-K_SHIFT { background-color: red; }
.android .kmw-keyboard-obolo_chwerty #caps-K_SHIFT { background-color: green; }

You may also want to use the “Shift Lock” key cap image for the Caps key on the Caps layer:

  • *ShiftedLock* (intended to depict a caps lock key, on)
    image

  • corresponds to *ShiftLock* (intended to depict a caps lock key, off)
    image

Noted as a bug report for Keyman Developer.

Noted; this was previously working so this is a regression.

This is solvable in the keyboard, in the detectStartOfSentence group:

  store(nl) d10 d13
  any(nl) > layer('shift')

This is solvable in the keyboard also, in your PostKeystroke group:

    if(&layer = 'alt') > context

The consistency issue is certainly something I want to investigate further (noted in same lexical model issue as above). I have noted a couple of state issues in the 15.0 beta with lexical models, and they are on my list to resolve.

The space and punctuation situation is currently not ideal. However, this is a separate feature to build, and I don’t think we’ll get that into 15.0 – time is running short for that.

That’s exactly what I wanted. Glad to know that this feature is already there.

That does it.

Solves it. Thanks.

1 Like

CAPS is working now. I can’t tell what changed. The codes are the same. I had updated the codes since the last time you tweaked them. I see that Keyman Dev. can now spot when there’s inconsistencies in the use of CAPS and NCAPS and notify kb authors. Thanks.

1 Like

I should note that an easy workaround is to do find/replace in the Code tab of the Wordlist tab; given this I will not prioritise a fix here (other more crucial issues to fix!)

I am getting


I’m on Windows 11 beta channel
I tried multiple online solutions, registry edits, starting the service, trying to uninstall Keyman Dev 14 (which fails with the same error)

Hey @dhigby, I don’t think this is specific to Keyman Developer. It looks like an issue with the Windows Installer Service.

I’ve taken a quick look around online and cannot find anything directly related. I noticed that the Windows Installer Service appeared to stop when trying to run the install/uninstall when you showed me yesterday. This sounds like it is crashing internally, which may mean some data corruption or something like that?

You should check Reliability History (not sure what it is called in Win11) and Event Viewer to look for events around Windows Installer – there may be some clues there.

Longpress pop-ups appear uninvited, and persist

Once in a while longpress pop-ups appear when one has not long-pressed the key, and will not go away except you press another key or switch layer. Sometimes they block the way to required keys, and moving the insertion point will not remove the pop-ups.

Apps Used:
Google Keep, Google Chrome, Google Notebook, Word Web dictionary.

Keyman Version:
15.0.225 and 15.0.228

Platform:
Android, 8.1

Device:
Tecno POP 2

@katelem, thanks for the report. Can you reliably reproduce this? Obviously we need to get to the bottom of it but if there are reliable steps to ‘make it happen’ – even if it takes a few goes – then that will help us diagnose it. (I ask because I haven’t observed this on my phone.) @darcy you might like to be aware of this.

Follow up. I found one repro, does this match with your experience?

If you hold backspace then touch another key, the key preview for the second key is left on-screen when you release both keys. (Backspace may not be the only key which triggers this – I think it’s related to keys which don’t have a key preview, but not sure.)

I’ll write this up as an issue – it’s a start: https://github.com/keymanapp/keyman/issues/6489

I simply type with the keyboard, and before I will finish a paragraph, longpress pop-up just appears. Sometimes it happens on keys that have not been pressed, other times it happens on keys just tapped. As I’m using this keyboard to type this reply, it has happened three times (+1 as I type the PS).

PS: I’m now using Keyman 15.0.231-beta

@katelem, are recent betas any better here? We will definitely hold off releasing until this is resolved.

I just downloaded 15.0.246. The issue is still there. (It has happened thrice as I type this reply).

I think you should go ahead and release it. The start of sentence detection and double-tap to CAPSLOCK, etc. are major improvements and users will be glad to see them.

Okay, thank you @katelem. @darcy are you able to investigate this in 15.0-beta?

With 15.0.248 beta, I think I have a repro:
On a physical device using the default sil_euro_latin keyboard with suggestions enabled, if I type “reply” a few times, eventually the long-presses for y appear and temporarily stuck.

The popups don’t trigger when typing into an Android emulator with Android Studio.

I suspect the device is detecting a long-press MOVE so the long-press keys are left being displayed.

@katelem, we released a patch in 15.0.251-beta which we think resolves the sticky longpress keys issue. Are you able to verify that it resolves the problem for you?

Yes. I’m currently using 15.0.253-beta; and as I use the keyboard to type this reply (and other text previously), I can’t see the pop-up issue again. So, the issue has been resolved.

:tada: Hurrah! Thank you for following up! :tada: