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

[WIP] [build wheel] Introduce TextInput provider (Android, iOS and "Legacy" Window provider) #8226

Open
wants to merge 15 commits into
base: master
Choose a base branch
from

Conversation

misl6
Copy link
Member

@misl6 misl6 commented Apr 29, 2023

Maintainer merge checklist

  • Title is descriptive/clear for inclusion in release notes.
  • Applied a Component: xxx label.
  • Applied the api-deprecation or api-break label.
  • Applied the release-highlight label to be highlighted in release notes.
  • Added to the milestone version it was merged into.
  • Unittests are included in PR.
  • Properly documented, including versionadded, versionchanged as needed.

A little brief

This is definitely not intended to be merged as-is, instead is just a POC for supporting additional textinput methods. (The idea is to treat the textinput provider as other core providers we have in Kivy (Camera, Window, ...))

It works (but sometimes it crashes, as I needed to achieve a result, and I did not took care about everything 😀) on both iOS and Android with platform-specific providers, and offers the same support as before with window-provider events on other platforms.

POC.mp4

Why this is needed?

  • The window provider (SDL in that case) does not have (and is not required to?) all the events and methods to access the complete feature set that the (mostly mobile) platforms offer.
  • We currently only support basic text input methods (we basically receive keystrokes from the keyboard and change the TextInput widget text property accordingly). This may be fine for languages that do not require an Input Method Editor (IME) to input text.
  • The window provider (SDL in that case) is not able to handle multiple TextInput fields at the same time. That breaks the keyboard suggestions for us.
  • The current implementation does not allow us to handle autofills (E.g. for password managers)
  • The current implementation does not allow us to handle accessibility features on textinputs.

Some related issues:

How we tried to fix this issue in past:

  • Disabling the keyboard suggestions (spoiler: does not work for all the soft keyboards)
  • Using textinput events from SDL (spoiler: these events are not enough to handle everything)

TODO:

  • Re-think FocusBehavior, possibly without breaking the current API. The keyboard needs (and should) be handled by the textinput provider.
  • ...

@misl6 misl6 force-pushed the feat/textinput-provider branch 2 times, most recently from e8ee360 to 442dd93 Compare June 25, 2023 14:56
@misl6 misl6 changed the title [WIP] POC: Introduce TextInput provider (Android, iOS and "Legacy" Window provider) [WIP] Introduce TextInput provider (Android, iOS and "Legacy" Window provider) Jun 25, 2023
@misl6 misl6 changed the title [WIP] Introduce TextInput provider (Android, iOS and "Legacy" Window provider) [WIP] [build wheel] Introduce TextInput provider (Android, iOS and "Legacy" Window provider) Oct 1, 2023
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.

None yet

1 participant