spec(web): Keyman Core integration for Web

[ermshiperete]

Introduction

Currently Keyman Core is only used on the desktop platforms (Windows, Mac, Linux). Keyman Core supports KMN as well as LDML keyboards.

Keyman Engine for Web has a separate implementation that only supports KMN based keyboards. This is also used by Keyman for Android and Keyman for iOS.

Keyman Engine for Web currently doesn't use the .kmx keyboard files but .js files that get generated by kmc as well.

Keyman Core doesn't deal with touch and OSK aspects of a keyboard.

LDML keyboards use an enhanced version of KMX (KMX+).

We would like to integrate Keyman Core in Keyman Engine for Web.

Architecture

• Keyman Core API will be accessed through WASM
• OSK will continue to be handled by Keyman Engine for Web
• Keyman Engine for Web will read a subset of KMX+ for touch layout/OSK
• Keyboards in .js format will be deprecated (probably v19). Instead we use .kmx everywhere.

Implementation

Refactorings/Cleanup in Keyman Engine for Web (#11374)

• move gesture-recognizer, input-processor, keyboard-processor from common to web/src (do we still need {input,keyboard}-processor in the future or will this be replaced by Core?)

• for clarity, rename KeymanEngine.core to KeymanEngine.inputProcessor

• rename keyboardCache to keyboardStore (and StubAndKeyboardCache to StubAndKeyboardStore?)

• chore(web): restructure repo #11374

Changes required to Keyman Engine for Web

• check backspace code - nothingDeletable - make sure LDML's return is understood by the K_BKSP fixup code
• probably want a new subclass of KeyboardHarness (or KeyboardInterface, or in-between) for LDML
  • add interface KeyboardHarness -> AbstractKeyboardInterface -> KeyboardInterface
  • add new class CoreKeyboardInterface
• KeyboardProcessor needs to know when to load CoreKeyboardInterface
  1. set KeyboardProcessor.activeKeyboard called by another layer
  2. caller will need to be able to load a .kmx instead of a .js

KMX Loader

Keyman Engine for Web will load .kmx files instead of .js. The .kmx loader should detect at load time if first bytes are KXTS and treat it as kmx, otherwise eval() as a script reject it and it will be loaded by the existing .js loader.

• Onscreen keyboard - and layer ids will need some wrangling.
  • setNumericLayer
  • should be generic intent stuff

Changes required to Core API

• core API will need to have a concept of layerId

Related issues and discussions

• Design discussion

[mcdurdin]

The .kmx loader should detect at load time if first bytes are KXTS and treat it as kmx, otherwise eval() as a script.

I don't think we want to do sniffing and eval as script. The pathway for loading a .js keyboard right now is injecting as a <script> element. The new pathway will take a blob from a source tbd and should just reject it if it doesn't start with the KMX magic bytes KXTS.