Skip to content
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

More visual options for gesture typing #944

Merged
merged 18 commits into from
Jul 25, 2024

Conversation

devycarol
Copy link
Contributor

@devycarol devycarol commented Jul 4, 2024

This patch creates 2 new options for gesture typing visuals:

  1. Whether the floating preview follows the user's finger or just statically hovers above the keyboard
    • This responds to the system setting for transitions being disabled, honoring a "reduced motion" need.
    • I've tested to make sure this works well on tablets and landscape orientation.
  2. The lifespan of the gesture trail. I enjoy this! You can make it a lot zippier :)
    • This also adjusts the preview linger timeout by division, the previous default of which is preserved.

More pondering...

This closes #942. even though I've not done adjustable trail width yet. If added, that'd need to apply to the regular trail as well as the sliding one. In the future, I think it'd be a good idea to do that and also disable the sliding trail with the regular one. More reduced motion 😌

That'd entail making the gesture settings page always visible, since the sliding trail is relevant regardless of whether a library is loaded. Maybe you could move a few more in there too, like the library loader and key swipe stuff.

@Helium314
Copy link
Owner

Whether the floating preview follows the user's finger or just statically hovers above the keyboard

Why? You can just disable the floating preview and see the word in suggestion strip.

The lingering time of the floating preview

Why? I can see that you would want it shorter, but im my opinion just reducing the default would be enough. (I'm not sure why this time actually exists, but I don't use the floating preview except when testing).

This is the reason for changes to the translation files, but beware that I'm no linguistics expert.

Please do not change existing translations. The string name might not be fully correct any more, but iirc that's the case for some others too.

@devycarol
Copy link
Contributor Author

devycarol commented Jul 12, 2024

The static preview is a reduced-motion visual option that looks nice. The center-suggestion can be pretty cramped, especially if there's a lot of toolbar keys. The moving preview can be hard to track with your eyes, while the static one keeps that visual prominence without moving all over the place.

It's good to have this as a way of honoring system reduced-motion without turning the preview off entirely. It also looks less janky when gesturing with multiple fingers, even if recognition for that still isn't really there. I really prefer it myself, and the code for it is really simple.

I've simplified the preview timeout configuration. Rather than have its own setting, it's just the trail fadeout duration divided by four—equal to the previous default. This really simplifies the settings and looks pretty slick across the board, compared to the unnecessarily janky configs you could do before. From this, I consider that "todo: make configurable" to be resolved.

@devycarol
Copy link
Contributor Author

devycarol commented Jul 13, 2024

I've once again broken my branch and need to shove it back to normal...

@devycarol devycarol marked this pull request as draft July 13, 2024 16:53
@devycarol
Copy link
Contributor Author

There's just a few bullet points before I consider this "complete."

How to handle the old translations for "Dynamic floating preview?" I've assumed the summary is no longer reliable across languages for one or the other, so it's been removed. Currently, the string gesture_floating_preview_text has been refactored to gesture_floating_preview_dynamic, but this should also be deleted if it's unreliable.

If animations are toggled in the system settings, the moving preview setting is updated to match. But currently, this only applies when the app is initially loaded (reboot, force stop, etc.) or the keyboard theme is force-updated by the gesture settings page. Is there a simple way to watch for changes to that setting and force-update as needed? Not that folks are toggling animations regularly, but it would be best for polish.

Speaking of, I tried applying the force-update approach to my fast typing cooldown setting as well, but GestureStrokeRecognitionParams seems to be an unaffected case. Is there a different reload method that could be used, or would it be feasible/wise to include that class as part of the force-update?

@Helium314
Copy link
Owner

I've simplified the preview timeout configuration. Rather than have its own setting, it's just the trail fadeout duration divided by four—equal to the previous default.

Sounds fine, thanks!

It's good to have this as a way of honoring system reduced-motion without turning the preview off entirely

Alright, then let's have it in there.

Is there a simple way to watch for changes to that setting and force-update as needed?

Possibly there is some listener for system settings. Did you check whether this triggers onConfigurationChanged?

Speaking of, I tried applying the force-update approach to my fast typing cooldown setting as well, but GestureStrokeRecognitionParams seems to be an unaffected case

This is unexpected. GestureStrokeRecognitionParams are created in PointerTracker.init, which is called when creating a new MainKeyboardView. As far as I remember this should happen on theme change.

How to handle the old translations for "Dynamic floating preview?"

Existing strings should not be changed, even if the name does not match any more. I found that any change has too much potential for creating issues with Weblate. You can adjust the comment above the string, as far as I know this is shown in Weblate.

Maybe you could name the new floating preview setting something like static_floating_preview?
Removing the summary is fine if it's not correct any more.

@devycarol devycarol force-pushed the gesture-visual-options branch from 83da7fb to 21de7e7 Compare July 19, 2024 01:14
@devycarol
Copy link
Contributor Author

they call me wood chips because my branches are broken.

Ok anyways, I've given up on that listener because I just couldn't get it to apply the change when triggered. Similar situation to the fast typing cooldown, something in there just causes those setting values to lag behind in certain circumstances. For now, it should adapt to system reduced motion at install and reboots. I can finagle it later, maybe it has something to do with that loadSettings TODO. But man, I Log.D'd to make sure the settingsvalues instance had the right values and everything and that reload just wouldn't happen.

The best clue that I have is that I don't see the MainKeyboardView constructor actually explicitly invoked anywhere.

String keys have been fixed to not change, summary string is deleted. We now have static preview and configurable gesture trail lifespan.

@devycarol devycarol marked this pull request as ready for review July 19, 2024 01:30
@devycarol
Copy link
Contributor Author

they call me wood chips because my branches are broken.

Ok anyways, I've given up on that listener because I just couldn't get it to apply the change when triggered. Similar situation to the fast typing cooldown, something in there just causes those setting values to lag behind in certain circumstances. For now, it should adapt to system reduced motion at install and reboots. I can finagle it later, maybe it has something to do with that loadSettings TODO. But man, I Log.D'd to make sure the settingsvalues instance had the right values and everything and that reload just wouldn't happen.

The best clue that I have is that I don't see the MainKeyboardView constructor actually explicitly invoked anywhere.

String keys have been fixed to not change, summary string is deleted. We now have static preview and configurable gesture trail lifespan.

@Helium314
Copy link
Owner

maybe it has something to do with that loadSettings TODO

btw all the TODO (uppercase) are still from AOSP (or possibly from OpenBoard)
I have completed or removed a bunch already, but there are still lots around which I didn't check, or didn't decide whether something should actually be done.
(mabye it's time for a mass-edit to clarify this everywhere)

The best clue that I have is that I don't see the MainKeyboardView constructor actually explicitly invoked anywhere.

Ah, the wonders of the Android view system...
It's only in input_view.xml, and since it's inside InputView, a new instance of MainKeyboardView should be created whenever a new InputView is created (KeyboardSwitcher.onCreateInputView).

Do you want to try some more? If not, I'd merge it as is.

@devycarol
Copy link
Contributor Author

I'm definitely dormant on the settings listener for now, I'll come back to it once I've learned more about how Android works.

I don't plan on any more work here, but I'll open a minor issue about the aforementioned things.

@Helium314 Helium314 merged commit 83ae078 into Helium314:main Jul 25, 2024
1 check passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

More visual options for gesture typing
2 participants