Select the closest key on swipe #138
Conversation
There was a problem hiding this comment.
Very interesting, thanks !
The computation of direction is very elegant and it seems to improves accuracy.
However the getAtDirection function seems a bit buggy. For example swiping right on the backspace key will hit backspace but down-right will hit delete. It also doesn't seem to have a consistent "closest key" behavior depending on direction.
I've modified this function, let me know what you think.
There's a bug remaining in this function: _handler.onPointerSwipe is allowed to return null, meaning it can remove a key depending on flags. The previous code tried hard to behave the same as if there were no key at all.
For example, on the QWERTY layout, the p key has placeholder keys for F11 and F12 that are normally hidden, they interfere with the calculation for the 0 key.
To fix that, the loop should be moved back to the Pointers class and should try _handler.onPointerSwipe on possible keys before returning.
| @@ -146,34 +146,42 @@ public void onTouchMove(float x, float y, int pointerId) | |||
| Pointer ptr = getPtr(pointerId); | |||
| if (ptr == null) | |||
| return; | |||
|
|
|||
| // The position in a IME windows is clampled to view. | |||
| // For a better up swipe behaviour, set the y position to a negative value when clamped. | |||
There was a problem hiding this comment.
Not the case on my devices! Nice bug fix.
There was a problem hiding this comment.
Oh, I forget to mention that. I tried to find a workaround or documentation for that, but I only found this Stack Overflow post: https://stackoverflow.com/a/41208273.
I see this behavior on my Android 11 device. Maybe I test that on my old Android 6 device to see if this happens there.
The keys
To be honest, it took me some time to understand how the loop works, but I think it is better than my. Your function is currently getting the first or second-closest key, which is a more intuitive behavior than getting even the opposite key as my function was doing, and even if not, you can easily adjust the range by only changing the loop condition.
I have found about it early today. If you want, I can fix that on the next weekend, but feel free to merge this in the current state. |
You are right, the condition is a bit too soon. |
fix a direction
getAtDirection was too hard to maintain and might contain bugs. Change slightly the meaning of directions and implement a the nearest key calculation as a loop.
The "closest key" logic must be careful not to reveal keys removed by a modifier. Must check [_handler.onPointerSwipe] for every candidate values. [selected_value] is changed back to [selected_direction]. This adds a new bug: When the direction change, the selected value might not change but a vibration will be triggered anyway.
Fix the bug introduced in the parent commit.
|
That was a great improvement! I just wanted to say thanks!!! 😁 |
I have seen a Google Play review (in Portuguese) suggesting (among others) that 0 could be recognized with an up swipe, regardless of the direction (since the 0 has a different direction from the other numbers, probably).
So I decided to solve this by always choosing the closest key to the swipe direction. So instead of computing the index of the key in
onTouchMove, I compute the direction of the swipe (from 1 to 8, 0 is no swipe) and I replacedKey.getValuebyKey.getAtDirection, which finds the closest key and handlesedgekeys. NowPointerkeeps track ofselected_valueinstead ofvalue_index.