Repository navigation
Conversation
|
Hello, just checking if this final touch to my previously solved issue was tested? Not rushing you or anything, asking in case it needs fixing :) |
|
Honestly now when i think about it, maybe is better not to implement this as will be unnatural, forget about this and release stable version of app with your solution with 2D backspace for now as it works good, i'll have to think of better solution for that vertical/diagonal delete swipe overall for some future update instead of using your fixed 40 characters, sorry for giving you trouble with this |
|
Ill be offline for 2 days |
No worries, take your time to rest well there! Sorry if it looked like i was rushing you, you can look at my other PR whenever you can! (you can ignore this one) |
2 participants
Delete swipe: larger deselect step for right swipe after a (nearly) vertical swipe
Follow-up to the 2D delete swipe deselection added in beta 9 (LeanType issue #467).
Problem
After a vertical delete swipe (selection grows upwards line by line), the right swipe now
deselects text on the reached line. But the finger is usually still close to the right edge
of the screen, because the delete key is on the right, so there is very little room for the
right swipe. In char mode one step is 10 dp per character, so deselecting a phrase like
"Testiranje ovoga" (17 chars, ~170 dp) is not possible in the remaining space.
In practice the upward swipe is rarely perfectly vertical: users unconsciously make a slight
diagonal (a little to the left) to gain some room on the right side.
Screen_Recording_20261016_205217_NotallyX.mp4
Change
All in
app/src/main/java/helium314/keyboard/keyboard/KeyboardActionListenerImpl.kt.New companion function
scaleDeleteSwipeDeselectSteps(stepsX, lineIndex, horizontalOffset, multiplier, tolerance).It multiplies
stepsXonly when all of these are true:stepsX > 0(rightward step),lineIndex > 0(selection base is on a line above the swipe start, i.e. a vertical swipe happened),horizontalOffset <= tolerance(at mosttolerancechars/words were selected to the left of thatline start, i.e. the swipe was vertical or only slightly diagonal).
Constants:
DELETE_SWIPE_DESELECT_CHAR_MULTIPLIER = 4DELETE_SWIPE_DESELECT_CHAR_TOLERANCE = 4DELETE_SWIPE_DESELECT_WORD_MULTIPLIER = 2DELETE_SWIPE_DESELECT_WORD_TOLERANCE = 1onMoveDeletePointerChars2D):actualSteps(...)receives the scaled steps, so code pointalignment (surrogate pairs) still applies.
onMoveDeletePointerWords2D):deleteSwipeWordIndexis changed by the scaled steps.minOffset/minIndex) are unchanged, so a scaled step can never movethe selection start past the position where the swipe started.
Why this rule (and not a broader one)
The larger step is only needed when the finger has little room on the right. That is the case
right after a (nearly) vertical swipe from the delete key. Making the larger step apply after
any previous swipe was considered and rejected:
it has plenty of room. A 4x step would also make the selection shrink 4 times faster than the finger
moves back: it would reach the start while the finger is still halfway, and small corrections
(1-2 characters), the most common use, would become impossible. Not scaled.
has deliberately selected text to the left, so the right swipe needs fine control to undo exactly
that part. Not scaled.
real gestures, because a "vertical" swipe almost always has a small leftward drift (1-3 chars). The
first right steps would only undo that drift at normal speed, and the larger step would start late.
The tolerance (4 chars / 1 word) treats such slight diagonals as vertical.
is the most direct measure of "little room", but it needs changes in
PointerTracker.kt, next tothe thumb-drift filter, and is a larger and riskier change. Not done here; the tolerance rule is a
good proxy with a much smaller change.
Where the larger step is NOT applied
PointerTracker.ktis not modified, so the thumb-drift filter and forward delete are notaffected. Other callers of the 1-argument
onMoveDeletePointer(steps)always stay on lineindex 0 and are not affected.
Tests
WordDeleteSwipeTest.kt: three tests forscaleDeleteSwipeDeselectSteps(vertical-only, slightdiagonal within tolerance incl. the boundary values and word mode, and the not-scaled cases above).
Not verified
Not compiled and the tests were not run (no Android build available to me). Please run
WordDeleteSwipeTestand try it on a device in char mode and word-by-word mode:vertical + right, slight diagonal + right, sharp diagonal + right (step must stay normal), and
horizontal-left + right (step must stay normal). The multipliers and tolerances are plain
constants and can be tuned if 4 chars / 2 words per step feels too coarse or too small.