-
-
Notifications
You must be signed in to change notification settings - Fork 111
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix(web): fixes up-flick shortcut issue for longpress when keys support downflicks #11216
Conversation
User Test ResultsTest specification and instructions
|
// Needs to beat flick-start priority. | ||
resolutionPriority: 4, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For reference, flick-start
is specified at priority 3.
keyman/web/src/engine/osk/src/input/gestures/specsForLayout.ts
Lines 731 to 734 in b4ed832
export function flickStartModel(params: GestureParams): GestureModel<any> { | |
return { | |
id: 'flick-start', | |
resolutionPriority: 3, |
this.gestureParams.longpress.flickDist = 0.25 * this.currentLayer.rowHeight; | ||
this.gestureParams.flick.startDist = 0.15 * this.currentLayer.rowHeight; | ||
this.gestureParams.flick.startDist = 0.25 * this.currentLayer.rowHeight; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I opted to increase the minimum distance for a flick start due to #10647 - if the existing threshold for quick longpress triggers is already too permissive, reducing it would only make things worse. Thus, increasing the flick-start threshold to match is the safer way forward.
Additionally, #10647 probably indicates that the flick-start threshold needed to increase anyway - if 25% of key height is too permissive for one gesture, it likely is too permissive (as a minimum) for all of them.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks like a nice and easy fix 😄
Test Results
|
Changes in this pull request will be available for download in Keyman version 17.0.307-beta |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
I happened to notice this one yesterday while using
sil_euro_latin
- our up-flick shortcut for quick longpresses wasn't working.Rather than make things convoluted with special-case handling this close to release, I figured the simplest way forward is to simply parameterize longpresses and flicks in a way that allows the longpress-flick to win when a key supports both. The old parameterization locked in the start of a full-fledged flick gesture before the longpress up-flick shortcut had a chance to trigger.
User Testing
TEST_LONGPRESSES_AND_FLICKS: Using the
sil_euro_latin
keyboard, verify the following: