refactor(web): banner integration with the new gesture engine 🐵 #9752
Conversation
User Test ResultsTest specification and instructions User tests are not required Test Artifacts
|
| * an ongoing contact-point event series. This class standardizes to .pageX | ||
| * (document) coordinates, rather than .clientX (viewport) coordinates. | ||
| */ | ||
| class InputEventCoordinate { |
There was a problem hiding this comment.
This comes straight out of the previous file in GitHub's changed-file listings. I've simplified it to include only the functions that are still utilized.
There was a problem hiding this comment.
The remaining bits are 'small enough' that it's probably not worth the effort at the immediate moment to shift paradigms for this file's exposed class.
| * @param startCoord The initial coordinate of a currently-ongoing input event | ||
| * @returns | ||
| */ | ||
| private applyScreenMarginBoundsThresholding(baseBounds: BoundingRect, |
There was a problem hiding this comment.
The inspiration behind the "safe zone padding" gesture-engine feature. As it lives there now, we no longer need it here.
| * an ongoing contact-point event series. This class standardizes to .pageX | ||
| * (document) coordinates, rather than .clientX (viewport) coordinates. | ||
| */ | ||
| class InputEventCoordinate { |
There was a problem hiding this comment.
The remaining bits are 'small enough' that it's probably not worth the effort at the immediate moment to shift paradigms for this file's exposed class.
|
So, relative to #9719, at this point this PR's deletions save about 12 KB minified. Not as much as I hoped, though it is something. Once all gestures are implemented, maybe I should go back and investigate the stats properties and either drop the ones we don't end up needing or relegate them to an unreferenced subclass that can be tree-shaken. That would probably give us some additional file-size refunding. Also, upon investigating the minified source, there are a few bits I had expected to see tree-shaken that weren't; remedying that would certainly be helpful. |
|
... and it was something really dumb on my end from a while back. There's a big difference between In my local build, this fix brings KMW down from 471,845 bytes to 451,879 bytes, a difference of about 20 kB. I'd say that's significant. |
jahorton
force-pushed
the
refactor/web/banner-gesture-integration
branch
from
6358c1f
to
4f5ab67
Compare
jahorton
changed the base branch from
feat/web/longpress-restoration
to
feat/web/subkey-corrections
…web/banner-gesture-integration
…web/banner-gesture-integration
web/src/engine/osk/src/input/gestures/browser/pendingMultiTap.ts
Outdated
Show resolved
Hide resolved
| // * @param touch The starting touch coordinates for the gesture | ||
| // * @returns | ||
| // */ | ||
| // initGestures(key: KeyElement, input: InputEventCoordinate) { |
…web/banner-gesture-integration
While #9657 started the process for integrating the new gesture engine with the main keyboard within KMW, it did nothing in regard to the predictive-text banner. This PR remedies the discrepancy, replacing its input-event interpretation engine with the gesture-recognizer as well.
Having both
VisualKeyboardandSuggestionBanneruse the same engine means we can now go through the code and remove all references to the old event-interpretation engines. (Plural - because I tried to make a generalized one before that never actually got used in both places... just one.) Of course, the new gesture engine is significantly more 'featured' than the old engines, so we'll likely still get a net filesize increase overall... but at least discarding the old engines should make the increase less severe.@keymanapp-test-bot skip