Keyman 17.0 Beta Release

@Marc It seems this double-tap delay issue has been resolved in 17.0.303. If otherwise, I will let you know.

A day or two ago we pushed fixes for the bugs I mentioned. There’s still some pending optimization work, but the stuck-keys problems and such should be fixed on our most recent beta builds now. Please let us know if you continue to see such errors!

Joshua H.

1 Like

If you select text, and double-tap (with the intention of switching to CAPS LOCK layer) the selected text gets deleted. Switching to other layers (default, shift, alt, num) does not delete the selected text.

Please note that I’m very happy with this fix. It’s a great relief. Just extend the fix to CAPSLOCK layer.

Spec:
Android 12, Tecno POP 7
Keyman 17.304 & 17.308
Obolo Chwerty 1.5 & SIL EuroLatin 3.0.1

1 Like

FEEDBACK 2: LONGPRESS DELAY, POP-UP ARRANGEMENT AND SELECTION

(i) Consider reducing longpress delay. In Gboard, it’s about 300ms, and users can change it to suit their preferences. See my previous report on this issue here [Deadkey on Shift Layer not working as intended - #14 by katelem]

(ii) In other keyboards, the longpress pop-ups are arranged so that the travel distance is minimal. In Keyman they are all arranged in a line making some pop-up keys far from the “parent” key, thus increasing travel distance. See screenshots:

(iii) In other keyboards, especially Gboard, when the longpress pop-ups show up, one is automatically selected. In Keyman it is not automatically selected; you have to do it yourself. This slows down fast typing.

Good catch, and I can confirm it on my own device. Documented as bug(web): layer-switching key multitaps clear selected text · Issue #11230 · keymanapp/keyman · GitHub.

1 Like

Thanks for the feedback @katelem!

More customisation of thresholds is on the agenda for a future release. This relates to accessibility. Note that if you start to flick upwards, this will immediately show the longpress menu as well – without waiting for the threshold timer to expire.

This is a good idea – can you open a feature request? This is the kind of thing we’d like to make more flexible in future versions.

This is supported in Keyman 17 – ‘default selection’ property of the longpress key:

1 Like

Yes. I just did it.

Thanks also for the default longpress pop-up selection you just pointed out in KM Developer.

1 Like

Right now it seems the keyboard author has to check this box for every key that has longpress. What if this can be done once, and it affects every key?

We intentionally wanted keyboard authors to choose which keys had a default longpress key, and which of the longpress options is “default”.

From issue #9416

  • Default will be selectable by keyboard designer – not necessarily the first, and may be none.

Some people may want the first longpress option as default, or the last, or the middle, or anything in between. It may be different for each key.

1 Like

@katelem thank you for the idea. As Darcy noted, and also the principle of batched editing of touch layout keys is something we do want to tackle – not just this aspect but coherently for all the key properties. Not sure when we will get to it though.

You could be clever with regular expression searching in the Code view to do all ‘sk’ arrays at the same time.

1 Like

But I’d suggest making a copy of your touch layout file before editing in Code view (just to be safe!).

1 Like

I’ve done default selection for some keys but those keys are not selected by default in the browser when testing the keyboard nor in the Android app. I still have to do the selection myself.

Spec:
KM Developer 17.0.294-beta
KM for Android 17.0.308-beta
Keyboard: Obolo Chwerty 1.5

I thought you might be referring to the version seen in Obolo Chwerty 1.5 by katelem24 · Pull Request #2701 · keymanapp/keyboards · GitHub, but I don’t see any subkeys set as default in the touch-layout file there. Are you referring to newer work?

I was going to test out your keyboard to verify and investigate the problem, but I don’t think I have access to the right version. The compiled .js keyboard or its .kmp would be enough for me to investigate with.

It’s a newer version. I’ve sent the kmp to your inbox.

1 Like

After upgrading to 17.0.318 beta, I noticed the default selection is working fine on my own end.

1 Like