Allow to disable the fast-typing swype lock

[devycarol]

Is your feature request related to a problem? Please describe.
The gesture handler blocks the start of a new gesture if it thinks the user is fast-typing. This is to prevent accidental gestures, but it often feels really clunky and unintuitive if you're a fast typer.

I used to think my phone was lagging out every time this happened, which is really unfortunate. I'd hate for people to think that their phones are worse than they are ;).

Describe the solution you'd like
There should be a setting to disable this behavior in the gesture settings. The relevant code is these two functions, as far as I can tell.

Use case
My fingers are pretty small and nimble, so I have no issues with removing the fast-typing timeout. The same can't be said for everyone else, so the setting would be off by default for obvious accessibility reasons. Another case where the block is still important is tablets, where you're more likely to type with many fingers.

Describe alternatives you've considered (if any)
Just reduce that cooldown time. The issue with this is that tablet users and the like may rely on that longer cooldown to not have unwanted gesture input. On the other hand, those who don't rely on the cooldown probably don't need it whatsoever.

[Helium314]

Could you describe the issue itself? You immediately jump to some section in the code, but from that I don't understand what your problem actually is, so I don't know how to look at it.

I don't even know which gesture you mean. Is is sliding input? Gesture typing? Key swipe gesture?

[devycarol]

Ah—gesture typing. You can replicate it by rapidly pressing keys and then trying to gesture a word. There's a cooldown that won't let you start one until a certain time/distance threshold has been reached.

The issue is that this often "false positives" in a disruptive way. It can have the appearance of system lag, and slows down typing.

The setting I made eliminates that cooldown if turned on. That's certainly preferable for my use case, and I think the setting is educationally beneficial—the user is made aware that the delay is intentional and not a performance issue.

[Helium314]

Thanks for the explanation! I see how this delay can be annoying.

Interesting how much functionality I never noticed even after many years of using AOSP keyboard forks... and another 2.5 years of playing with the code.