Fixes#6455.
This involved adding an extra hint to the data passed into the lexical
model layer, being the CasingForm that the current layer wants to use.
Given there are several entry points to the lexical model layer, this
meant a few places where we needed to check the current layer.
I refactored the very long function `InputProcessor.processKeyEvent` to
extract out the `buildAlternates` function. There should be no
functional changes to the `buildAlternates` code. But it makes
`processKeyEvent` significantly easier to read.
Fixes#6489.
The issue arose in multitap scenarios, where the tip display state
became desynchronised with the actual display state as maintained in
the Android code.
The fix I applied was to reduce some of the state checks into the js
wrapper android-host.js. This is not ideal. The state machine for key
tip display is scattered across four functions in three files:
* visualKeyboard.ts: VisualKeyboard.highlightKey
* visualKeyboard.ts: VisualKeyboard.showKeyTip
* embedded/keytip.ts: KeyTip.show
* android-host.js: oskShowKeyPreview / oskClearKeyPreview
I have moved the actual re-creation check for the tip to the lowest
level functions -- those in android-host.js. But a more detailed look at
the state machine and a refactoring would certainly be worthwhile.
Fixes#6455.
This involved adding an extra hint to the data passed into the lexical
model layer, being the CasingForm that the current layer wants to use.
Given there are several entry points to the lexical model layer, this
meant a few places where we needed to check the current layer.
I refactored the very long function `InputProcessor.processKeyEvent` to
extract out the `buildAlternates` function. There should be no
functional changes to the `buildAlternates` code. But it makes
`processKeyEvent` significantly easier to read.
This is a follow-up for #6331. We still did not have enough detail to
be able to trace the root cause of the load errors. This adds a little
more diagnostics.
