Repeatable arrow keys

[devycarol]

This patch improves support for the arrow keys in regular layouts:

• They are now repeatable.
  • Like the delete key, they will not persist audio/haptic feedback if there's no more movement to do.
  • This detection is recycled from the delete key for the back-movers, and a new detection is implemented for the forward-movers.
  • There are edge-cases in primitive input fields (e.g. terminal emulators) where the detection is unreliable. In these cases, the rightward detection is slightly less reliable than leftward. This will not affect the actual functionality of the keys, and they will still always make the initial keypress sound. So this is fine, there'll just be a little awkward silence in those cases.
• They no longer show a preview pop-up when tapped.
  • This is relevant for non-numeric layouts (doesn't affect the numpad-based prototype).
  • There are still a lot of editing/toolbar keys that aren't guarded against this. This is dismissable until a full navigation layout is implemented, when we might not want to universally disable pop-ups.

For testing, here's a D-pad prototype that you can replace your numpad layout with: dpad_toy_retro.json

In a separate PR, I'd like to make the 1.2x scale factor for the toolbar arrow keys apply universally (directly to the drawables themselves). This one's ready for merge on my part.

---

Split from PR #925
Progress on #357

[devycarol]

There's a separate issue with the arrow keys that I'd like to address later: they're pretty janky sometimes. The biggest offender I've seen is websites (I only use Firefox), where the cursor is prone to snap back to a previous position when you've used the left/right arrows. This coincides with how web text is a lot less friendly with text selection and the like. From what I can tell, the cause seems to be word-composition. The issue doesn't occur with physical keyboards, which don't have any of that underlining/correction.

Do we know why this happens? I recall a method "reset caches and return success" whose comment says that it should be called whenever the cursor has moved. I'd like to disrupt typical behavior as little as possible, but a brute-force option would be to temporarily disable that composition stuff whenever arrow events are happening.

Here might offer some insight: sendDownUpKeyEvent()—"batch edits" 🤔

[Helium314]

Please disable the repeat if the key has popup keys, this interacts quite badly.

There are edge-cases in primitive input fields

As discussed and you summarized: that's fine.

There are still a lot of editing/toolbar keys that aren't guarded against this

I will add some function to KeyCode, like Int.hasVisibleInput to be used for this purpose (i.e. when the input is not visible, no preview popup should be shown). Maybe the name could be improved though.

[Helium314]

I will add some function to KeyCode, like Int.hasVisibleInput to be used for this purpose (i.e. when the input is not visible, no preview popup should be shown). Maybe the name could be improved though.

Hmm, better to use suppressPreviewPopup, because it's not necessarily related to visible input (I don't think showing a preview icon for e.g. undo or tab is bad).
So not all toobar keys should get the ACTION_FLAGS_NO_KEY_PREVIEW flag, but only those where it makes sense (the ones moving the cursor, and maybe a few more).

[Helium314]

There's a separate issue with the arrow keys that I'd like to address later: they're pretty janky sometimes.

Ideally the arrow keys would not result in a key event for exactly this reason. Probably it would be better if they behaved similar to space swipe with a single step. Though such a change might result in other issues, as some text fields only want key events.
Detection when to use what is tricky, see also the convoluted logic in InputLogic.handleBackspaceEvent.

[devycarol]

Yup, I've spent a fair bit of time looking at that stuff. The space-swipe approach is less bug-prone but less reliable in primitive situations.

(I don't think showing a preview icon for e.g. undo or tab is bad).

Previews on icon-keys don't work well for some reason. The alignment for the preview and subsequent popup keys gets messed up.

[devycarol]

Force-pushed due to rebase.
I figured out the "proper" way is to sync my remote branch and then update my local one, so that's what I'll do moving forward.

Repetition is now disabled if a repeater has pop-ups. Ready to go on my end.

[Helium314]

Looks good, thanks!