-
-
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
change(web): locked flicks 🐵 #9957
Conversation
User Test ResultsTest specification and instructions User tests are not required Test Artifacts
|
#9991's changeset has now been folded into this PR; it was a pretty easy rebase -> ff-only merge. |
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
this.gestureParams.longpress.flickDist = 0.25 * this.currentLayer.rowHeight; | ||
this.gestureParams.flick.startDist = 0.1 * this.currentLayer.rowHeight; | ||
this.gestureParams.flick.dirLockDist = 0.25 * this.currentLayer.rowHeight; | ||
this.gestureParams.flick.triggerDist = 0.75 * 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.
Should these multipliers be consts at the top of the file?
Per a recent team meeting to examine how flicks felt, etc, this PR reworks flicks from the form seen in #9909 and #9825 to something that will hopefully feel smoother and more intuitive. To wit:
There may be a bit of fine-tuning to be done (that first reset attempt on the 'i' seems a bit odd), but the following criteria have been met:
There is a "fun" interaction between points 2 and 4 above:
As the flick-reset occurs (due to vector projection) while quite far from the original, base position, and there is no flick available in the new direction, the flick quickly cancels upon reset. That said, if there were a flick available in the new direction (via temp-edit)...
It feels a little abrupt, but not too much so. It's probably "fine"... or at least, low-priority enough that further polish work is "safe" to triage until a later point in time.
Note: I've revised things since the screen capture above, but that was done alongside work on #9972 and is hard to fully display without that. I've gone ahead and rebased the changes originally within #9991 onto this branch and done a
git merge -ff-only
; its code changes were near-entirely within the same files already changed here, so the review process should be simpler as a result... even if the child PR (#9972) is needed to fully appreciate certain aspects.As such...
@keymanapp-test-bot skip
User tests will be specified either on #9972 or on its followup #9973.