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

Android keyboard doesn't support swipe input and other common features on Entry #2331

Closed
hkparker opened this issue Jul 20, 2021 · 4 comments

Comments

@hkparker
Copy link
Contributor

Is your feature request related to a problem? Please describe:

With the Fyne demo app for android (installed via play store, let me know if that's out of date and this has been addressed and I can try to build the demo for mobile on develop), when the keyboard is opened for an Entry (including MultiLineEntry), it opens in a really "basic" way. Text can be typed, but the "swipe" input technique standard in the google keyboard seems disabled. Also, word suggestions in the bar above the characters don't appear, instead there's just numbers, and spell check seems disabled. The keyboard is presented, but in the most generic and simple way possible. I'd like to get the "full" keyboard experience one would receive when composing messages in any other app.

Is it possible to construct a solution with the existing API?

Not that I'm aware of.

Describe the solution you'd like to see:

I'm not an android developer, but based on experiences in other apps and websites developers seems to have some way to communicate to the OS which type of keyboard should be used. That must be how it "knows" when to just show a number pad when typing in a PIN for example. And I did find this, so there's already some Fyne analog for this. I don't know how the "full" keyboard is defined in android (or iOS for that matter), but having that defined in Fyne, and used when opening keyboards on Entry widgets, would be a massive improvement for the mobile user experience.

@andydotxyz
Copy link
Member

This may relate to #1453

@andydotxyz
Copy link
Member

We cannot (easily) support the suggested words (because reasons, could be addressed in the future with a much more complex Android driver).
However the swipe should work, this may be a separate issue.

@hkparker
Copy link
Contributor Author

hkparker commented Dec 15, 2024

Following up here years later: most of this appears to be present now! I can swipe to enter new words, I see word suggestions that are at least aware of my last word. I'm not sure if this was a Fyne change at some point, or if Android is just adding more to the default keyboard, but either way, it's there!

Two main things that are still missing I've noticed:

  1. When clicking over a word that was entered previously, they keyboard doesn't seem to know what word you're returning to, and can't suggest edits to replace the whole word. Not surprising, I bet that requires a tight integration with the entry widget, and is not something I'd expect in Fyne any time soon, but just calling out the common behavior.

2. I can't press and hold backspace. I get one character (or in the case of a swiped word, one word) at a time, then then the keyboard shows the button is being held down but nothing happens. Will open a separate issue for this. EDIT: it does delete multiple characters, just not smoothly and was confusing at first

For this ticket: should I just go ahead and just close it now? Or would you like to use this as a place to track ways Fyne's entry doesn't have feature parity with the native widget? I think it makes sense to close this out now and open more specific issues for any missing behaviors, since the general issue of the keyboard being super basic is no longer a problem.

EDIT: On account of the backspace actually doing something close to what I would anticipate with further testing, I think there's not much of a reason to keep this open, the ways in which mobile entry diverges from native now are pretty advanced and unrelated to the original issue. It might be nice to support "number pad" keyboard still as originally described, but the original spirit of this issue was that they keyboard was frustrating to use for normal typing, and that's no longer the case.

@andydotxyz
Copy link
Member

Agreed. Thanks for the feedback on this. The point of not matching text in place for sensible suggestions is a valid one due to how we currently work with the keyboard. Feel free to open a new ticket for that.

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

No branches or pull requests

2 participants