This is part of a broader specification for Caps Lock support on touch devices. Development of this touches multiple components; each component will be implemented in a separate PR, referencing this issue.

Related features

• spec: Start of text/sentence selects shift layer #3621: spec: Start of text/sentence selects shift layer
• spec: Suggestions respect capitalization #3720: spec: Suggestions respect capitalization
• spec(web,developer): multitap and flick for touch keyboards 🐵 #5029: spec: multitap and flick for touch keyboards

Introduction

A separate caps layer should be supported for touch layouts that provides support for Caps Lock semantics. This allows for slight nuances if there are differences between a caps and a shift layer, and also gives a clean pathway forward for existing keyboards that may have already defined nextlayer properties on each key.

If the keyboard defines layer controls in rules, these will not override nextlayer controls. According to spec, touch layout wins.

The caps layer, if present, will be accessible by double-tapping the Shift key. See #5029.

C1.1 File Formats: .keyman-touch-layout changes

Changes to the file format and the JSON schema are required.

1. Required: Add a caps entry to the list of predefined layers. The templates will not include this layer by default, as ideally Keyman Developer will include tooling to help generate the caps layer from the shift layer.
2. Optional: Add a property for each layer called nextlayer. When set, for each normal key on that layer that has no nextlayer set, this would be applied by KeymanWeb. (this resolves the tedium as discussed here.) The templates would be updated to set nextlayer to "default" for shift layers.

Backward compatibility

Touch layout files that contain these features will be backwardly compatible with earlier versions of Keyman, with a graceful degradation of functionality.

• (if nextlayer is implemented) The compiler will transform the nextlayer property from layer-level to key-level at build time. Existing per-key nextlayer properties would override the layer nextlayer property.

C1.2 Changes to Compiler

1. (if implemented) The compiler will transform the nextlayer property from layer-level to key-level at build time. Existing per-key nextlayer properties would override the layer nextlayer property.

C1.3 Changes to Developer IDE

• Optional: The touch layout editor needs to surface the nextlayer property for each layer.
• Optional: A helpful function would be to be able to generate the caps layer from the IDE.
  • A caps layer’s initial form may easily be made by duplicating its base layer.
  • No special wizard or anything needed there.
  • Keys that have overridden modifiers may need manual correction.
  • nextlayer properties on each key may need manual correction.
  • Updates to the shift layer will not auto-propagate to the caps layer.
• Optional: Also helpful would be some validation tests for nextlayer property consistency.

C1.4 KeymanWeb enhancements

• Required: KeymanWeb needs to support the Caps Lock layer.

Caps Lock Interaction: double-tapping Shift will switch to the caps layer -- see #5029.

Caps Lock Presentation: the caps layer Shift key needs treatment to differentiate from the Shift key on the shift layer. This will be through the caps indicator image defined as *Caps*. We should also consider colour styling, for example, this could be defined in the CSS with a rule for selector .kmw-key-shift#caps-K_SHIFT. The styling may differ per platform.

Related Issues and discussions

• Touch Layouts need to support permanent vs transitory layer selection #246
• https://community.software.sil.org/t/how-to-return-from-shift-automatically-and-how-to-caps-lock-by-double-tapping/3469/3
• https://community.software.sil.org/t/problem-with-caps-lock-output/3718
• Original design document
• RFC
• 15.0 planning document