Testing CAPS on Touch

Matthew_Lee · October 31, 2022, 10:09pm

So, Here’s a fun one.

TLDR: I tried implementing caps on multi-touch keys in the touch editor, but I specifically can’t do a nextlayer jump from a double-tap to rightalt-caps. It lands on the wrong layer.

Code here: keyboards/release/sil/sil_cameroon_azerty at master · MattGyverLee/keyboards · GitHub
The bug affects the four multi-touch keys I marked as T_CAPSRC.

Before implementing caps, the Cameroon Keyboards’ keys already returned to the default layer after typing something capital or special (i.e. typing an ‘ɛ’ on rightalt outputs the letter, then returns to the default layer.). With existing default, shifted, and rightalt layers, implementing caps and getting all the nextlayers right becomes…complex. See below for my map:

I first duplicated my shift later to become caps, made a few changes to the top row, and then removed all of the nextlayers from individual keys in the touch editor.
I duplicated the rightalt-shift layer to create rightalt-caps, and set the nextlayers to rightalt for individual keys in the touch editor.
Finally, I duplicated symbol to make symbol-caps (I don’t want going to symbol to cancel caps), and sent the nextlayers to caps.

I got to work making the modifier keys jump correctly, but I ran into problems with four multitaps.

I can’t use a double-tap to jump to rightalt-caps from rightalt or rightalt-shift, but I can get there by going to caps from default first and then to rightalt-caps via the Cameroon key.

I have made a new testing table, the whole set is described below:

Once it is fully working, I need to retest my symbol-caps layer which is hard to access.

I’ve had issues in the past with nextlayers configured in touch not going where they were supposed to, and got around it with a > nextlayer() rule in the code, but I tried that and it doesn’t seem to be working now. Is this another lazy selector (Marc’s words, not mine)?

In case K_CAPS was a reserved string (keyman/keyboardProcessor.ts at 65770747a3c71ceaec99758c1e2a64f158a69a7a · keymanapp/keyman · GitHub), the broken keys now have a KeyID of T_CAPSRC. Still no luck.

I am currently only testing Cameroon Azerty. My current changes are on the master branch of my personal public fork.

So…

Any ideas to make it right? Any ideas if you make code changes to keep this backward-compatible with KM15?

KM Dev 16.0.92. Windows 11, testing on Chrome for iphone and Android.

~Matthew

joshua_horton · November 1, 2022, 7:12am

If memory serves - and I’ll defer to @Marc here should he post more details - the decision was made that double-tapping for caps will only work for the base-level caps layer: default → shift → caps. No other caps-layer variants get the special treatment; we don’t have anything set up to check for -caps-suffixed pairings or layer ids.

I can’t use a double-tap to jump to rightalt-caps from rightalt or rightalt-shift, but I can get there by going to caps from default first and then to rightalt-caps via the Cameroon key.

This lines up with what I recall; you can get to caps from default and then move to a variant, but we don’t support rightalt → rightalt-shift → rightalt-caps or any other such pattern. Only default → shift → caps gets special handling.

Matthew_Lee · November 1, 2022, 3:27pm

Um, so if I’m understanding you, this is not only not allowed, but actively blocked in the code? Really? Doesn’t my use-case of jumping from rightalt to rightalt-caps make just as much sense as default to caps?

I wasn’t expecting “special” handling, just simple handling of what i configured it to do, nextayer:rightalt-caps.

joshua_horton · November 2, 2022, 1:13am

It’s not “actively blocked”, at least not intentionally. It’s more that we didn’t put in anything to support generalization of caps-multitap to any other layers. I do feel you; I was a proponent of trying to generalize, but the decision was made to not attempt generalization of the multitap caps for other, non-default layer types.

Now, looking a bit more directly at your code, what you’re actually running into is a different issue:

github.com

MattGyverLee/keyboards/blob/9a72626b18d3105546ecacafd4674be58f285ebf/release/sil/sil_cameroon_azerty/source/sil_cameroon_azerty.keyman-touch-layout#L1336-L1344


      
          "multitap": [
            {
              "text": "*ShiftLock*",
              "id": "T_CAPSRC",
              "sp": "1",
              "nextlayer": "rightalt-caps",
              "layer": "default"
            }
          ]

Custom defined multitaps like this (also, flicks) were originally planned for our 16.0 release cycle, but implementation of advanced gestures has turned out to be more complex than we originally envisioned (partly because the existing behaviors have accrued a lot of “technical debt” that would get in the way of long-term maintenance once more gestures are added) and has been deferred to 17.0 as a result. My personal apologies here, as I’m the developer who works most directly on the related parts of the codebase.

Marc · November 2, 2022, 7:17pm

As @joshua_horton noted, in Keyman 15, we made the decision to support only one, hardcoded double-tap gesture on Shift to move to the caps layer, which covers the majority of keyboards that need this functionality. This was intended as a stop-gap until we completed generic multi-tap gesture support, at which point you’d be able to define your own double-tap on Shift to move to any layer you desire. There were two aspects to this:

Support for defining multi-tap gestures in the .keyman-touch-layout file, now supported in Keyman 16 beta
Generalized support for multi-tap in Keyman Engine for Web, still in development

It would (in theory at least) be possible to improve our stop-gap measure for the Shift key to allow a double-tap to target an alternate layer, by making use of those additional multi-tap gestures bdefined in the .keyman-touch-layout file now. That change would meet your need for now but would be a dead-end change in that we’d be rolling it back out for full multi-tap gesture support. It would be a very constrained patch with caveats – it would only support layer switching with the nextlayer control, and not character output, so I am somewhat hesitant. But as far as I can tell, such a tweak would be forward-compatible with the format changes.

What do you think @joshua_horton? We’d be building this tweak with the plan to back it out with proper gesture support, so we’d only be reading the additional multi-tap data from the touch layout in order to get a different target layer name. The changes should be limited to pendingMultiTap.ts.

Matthew_Lee · November 2, 2022, 9:23pm

Thanks for considering a temporary patch to make this work.

The last time I had an errant/inconsistent nextlayer in the touch editor, I was able to workaround it by removing the nextlayer command from the Touch editor and wrote a rule in the Layout code which worked.

+ [T_UPPER] > nextlayer(rightalt-shift)

You know the code better than I do, but is there a chance I could adapt my keyboard in a nonbreaking way instead in this way (maybe even removing caps from rightalt-caps`), or do both now trigger the same code?

Marc · November 2, 2022, 9:35pm

No, I don’t think you can adapt your keyboard in the way you are hoping. The double-tap is currently a specific special case for caps layer. There is currently no way to control it from the keyboard code – if a caps layer is present, a double-tap on Shift will activate that layer. If we implement the tweak I mention above, then you’d have some basic control on which layer is activated, but that’s it until the full gesture support is complete.

drowe · November 2, 2022, 11:17pm

A possible workaround might be to make the caps layers a long-press key on the corresponding shift keys.

Marc · November 2, 2022, 11:45pm

And … here is a potential answer: feat(web): Custom layer targets for Shift double-tap by mcdurdin · Pull Request #7608 · keymanapp/keyman · GitHub

I have tested it locally with a hacked up version of your keyboard @Matthew_Lee, but it’d be good to get your eyes on it. I don’t know if you have access to TeamCity, but if you do, you could install the custom Keyman Developer build from the PR, once it builds in the next couple of hours, to test it locally?

Marc · November 3, 2022, 4:06am

This tweak will be available in beta 16.0.96, which will be built in the next 24 hrs.

Matthew_Lee · November 3, 2022, 11:02am

Thank you Keyman team for going out of your way for me again! I guess it is a symbiotic relationship as I stress-test your newest features and give you complex configurations you can use for regression testing.

I knew that caps was newly supported in web and didn’t realize that multi-tap was only partially supported until reading the beta release announcement.

With the new fix, the special jumps on my capped keyboard will only fully work with beta 16.0.96+ (I don’t expect this would be back-ported to 15), but should work as I’m currently seeing it (see testing table) in v15, right?

I’ll finish testing my full version on beta and probably rebuild my Android app with the beta KMEA (it has always been on a beta version). I can’t decide whether to submit a version to keymanapp/keyboards with a temporary bug no-one is likely to notice, or wait until 16 goes stable to submit a version including these four nextlayers.

Unless someone wants to give me access to teamcity or a zip, I’ll look for 16.0.96 when it builds beta. (Developer is suggesting 17.0.2 alpha which is too old to have the fix, so I’m waiting.)

Would it be helpful for me to write a mid-length article about the nextlayer considerations I had while working through this?

Marc · November 7, 2022, 12:36am

Yes, I think that’s correct.

For sure

Nyny · January 10, 2024, 9:04am

This topic was automatically closed after 14 days. New replies are no longer allowed.