feat(developer, web): Add support for a "Last Layer" identifier for the "Next Layer" field

[dyacob]

Is your feature request related to a problem? Please describe.

When working with many layers in a touch layout, there can be multiple ways to arrive at a given layer. That is, a given layer may be the target of more than one "next layer" property.

As a convenience for users, I would like to add a "back" button to return to the previous layer. Doing so is complicated (not possible?) when the previous layer is not tracked and cannot be specified.

Describe the solution you'd like

I would like the "Next Layer" dropdown menu to have a built-in, option for a macro like ":last_layer:", or whatever would be JSON safe.

Keyman will interpret this target layer as the previous layer that the user was on and reload it.

I imagine that in source code the layers are treated as objects, and a field might be added to track the previous layer. This would be useful to have, per-layer, to support multiple levels of "back".

Describe alternatives you've considered

An alternative that I use is to have layer "A" go to (next layer) "B_A", and layer "Z" goto to layer "B_Z". Where layers "B_A" and "B_Z" are both duplicates of a layer "B" that can in turn have "Back" / "Return" keys that point to layers ""A" and "Z" respectively.

This leads to unfortunate duplication of data that could be avoided if layers "A" and "Z" could both navigate to a single "B" layer that in turn could have a "Back" key with "next layer" target ":last_layer:".

Related issues

No response

Keyman apps

• Keyman for Android
• Keyman for iPhone and iPad
• Keyman for Linux
• Keyman for macOS
• Keyman for Windows
• Keyman Developer
• KeymanWeb
• Other - give details at bottom of form

Keyman version

No response

Operating system

No response

Device

No response

Target application

No response

Browser

No response

Keyboard name

No response

Keyboard version

No response

Language name

No response

Additional context

No response

[mcdurdin]

This is an interesting idea. Keyman at present operates in a state-free environment. One way you could accomplish this yourself (for a limited depth of back-tracking, anyway) is with the use of variable stores; you could do it with deadkeys but that interferes with text processing.

e.g.

if(&layer = 'a') + [T_B_LAYER] > layer(b) set(last_layer = 'a')
if(&layer = 'z') + [T_B_LAYER] > layer(b) set(last_layer = 'z')
if(last_layer = 'a') + [T_BACK_LAYER] > layer(a) 
if(last_layer = 'z') + [T_BACK_LAYER] > layer(z) 

Then, on the touch keyboard, you define your T_B_LAYER and T_BACK_LAYER keys without any layer-switch properties.

In theory you could make a 'stack' of these with a bit of clever programming on the kmn side, but there is probably limited value in having the Back key go back more than a handful of layers, as users won't remember anyway?

[jahorton]

We'd need to fully spec this idea out if we did adopt. The following scenario may

Layer A:

T_GOTO_B: emits 'B', swaps to layer B
T_RETURN: emits 'D', swaps to "last layer"

Layer B:

T_GOTO_A: emits 'A', swaps to layer A
T_RETURN: emits 'C', swaps to "last layer"

If I'm on "layer A" and use T_GOTO_B, T_RETURN (on layer B), T_RETURN (on layer A)... what layer should be active after the second T_RETURN? My personal expectation is that we'd end up on layer B again, and further uses of T_RETURN would constantly toggle between the two layers. The text output would be BCD, with further uses adding CD repeatedly.

I'm not sure if this would be intuitive to the majority of users, though.

---

One thing I would like to mention in this regard, though. For #5029 / #7324, one gesture-feature we're considering adding would be the ability to hold down a modifier key to temporarily swap layers, allow use of keys on that layer while the modifier is still held, and then return to the original layer when releasing the held modifier key. It would be kind of like a longpress, but where the key's destination layer is the set of "subkeys" for the modifier. The likely implementation: it would be automatically enabled, but only for plain modifier keys - no text output, no defined subkeys... just a 'nextlayer' attribute.

This approach would provide similar functionality to what you're requesting here, I believe. (Though, of course, "accessibility" concerns mean that some users may not be able to use said gesture-feature, should we get it implemented.)

We hope to get it in with the rest of the gesture work, but it's a bit early to guarantee that.