refactor(web): new abstraction - corrective layouts 🐵 #9778
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
User Test ResultsTest specification and instructions User tests are not required Test Artifacts
|
mcdurdin
approved these changes
Oct 18, 2023
Co-authored-by: Marc Durdin <marc@durdin.net>
Base automatically changed from
feat/web/longpress-restoration
to
feature-gestures
October 20, 2023 09:21
…ive-layout-abstraction
…ive-layout-abstraction' into refactor/web/corrective-layout-abstraction
…ive-layout-abstraction
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
With the new incoming types of gestures, it's important that we prepare a reasonable way to model them alongside the predictive-text engine. While we've long had a good setup in place for standard keyboard layers... none of the other uses cases have particularly great models.
Our existing longpress solution:
keyman/web/src/engine/osk/src/visualKeyboard.ts
Lines 578 to 583 in af3ba1f
Yeah, that's not ideal. Surely we can do better.
So, to provide a good path forward for our existing longpresses and for newly-incoming multitaps and flicks, this PR creates abstractions for the minimal requirements of the key-distance algorithm at the core of the fat-finger algorithm. It also extracts the key-correction methods from
ActiveLayer, allowing them to operate independently of any specific type - they'll now utilize the new abstractions.By doing so, it becomes possible to build appropriate values for the new abstraction for our subkey menus, allowing true fat-finger calculations for subkeys. (A major improvement over simply maintaining the existing hack.) It also provides a baseline for further enhancements we may wish to consider for corrections involving multitaps and flicks. Note that none of the ideas in this paragraph are implemented within this PR, though - I've kept the scope limited to just the refactor needed to facilitate implementations thereof.
An extra benefit from this refactor - the key-distance types and algorithms at the heart of the fat-finger algorithm have been moved to
input-processor, the same package containing the fat-finger algorithm. Asinput-processor's primary role is facilitating predictive-text and acting as the interface between keystroke-engine and predictive-text, it's the perfect place for them. (Not thatinput-processoris the perfect name, given the package's role.)@keymanapp-test-bot skip