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

Add support/enablers for custom/in-app virtual keyboards #68988

Closed
jpnurmi opened this issue Oct 25, 2020 · 9 comments · Fixed by #76072
Closed

Add support/enablers for custom/in-app virtual keyboards #68988

jpnurmi opened this issue Oct 25, 2020 · 9 comments · Fixed by #76072
Labels
a: text input Entering text in a text field or keyboard related problems c: proposal A detailed proposal for a change to Flutter customer: dream (g3) framework flutter/packages/flutter repository. See also f: labels. P1 High-priority issues at the top of the work list

Comments

@jpnurmi
Copy link
Member

jpnurmi commented Oct 25, 2020

Use case

Flutter should make it possible to override the default text input control.

The default text input control is hard-wired to a method channel that is used to communicate with the platform plugin. However, on embedded systems that do not have a system-wide virtual keyboard, it should be possible for an in-app virtual keyboard to register itself so that it can take over the text input communication.

Proposal

In essence, an in-app VKB should be allowed to:
a) intercept text input calls (respective to 'TextInput.xxx') from Flutter, and
b) provide text input responses (respective to 'TextInputClient.xxx') back to Flutter.

This would be possible if there was a way to register a custom text input control that would override the default text input control. Notice, however, that even with custom text input controls it is important to keep some of the text input method channel communication intact to ensure that text input with e.g. physical keyboards continues to work.

Related packages

There is a basic virtual_keyboard package on pub.dev. Notice that it's just a widget with a callback for key presses. Since it has no way to integrate with Flutter and specifically TextField, the example is simply collecting key presses into a Text label and has a toggle button to tell the VKB whether it should present a textual or a numeric mode. While this approach "works" for a trivial single page example, it does not really scale that well for real-life apps with multiple screens and input fields.

Proof of concept

I have made a proof of concept implementation based on the above proposal and the virtual_keyboard package. Here's a video that shows it in action, running with flutter-pi on a Raspberry Pi 4: https://www.youtube.com/watch?v=zgiiThQCU1E

@pedromassangocode
Copy link

Cc @justinmc @LongCatIsLooong

@pedromassangocode pedromassangocode added c: proposal A detailed proposal for a change to Flutter a: text input Entering text in a text field or keyboard related problems framework flutter/packages/flutter repository. See also f: labels. passed first triage labels Oct 26, 2020
@justinmc
Copy link
Contributor

This is really awesome, thanks for the proposal! It never crossed my mind that there might be a reason to write an in-app keyboard in Flutter, but this definitely makes sense for IoT platforms with no system keyboard.

Would you be willing to turn your proof of concept into a PR? I'm happy to help with reviews or anything else.

CC @gspencergoog who has worked on Linux keyboard support.

@jpnurmi
Copy link
Member Author

jpnurmi commented Oct 27, 2020

I'm glad you like the proposal! I can start cleaning up the experimental patches I have lying around.

@jpnurmi
Copy link
Member Author

jpnurmi commented Oct 27, 2020

I have opened a PR: #69146

jpnurmi added a commit to jpnurmi/flutter that referenced this issue Dec 31, 2020
The existing TextInputConnection class has been made abstract and
method channel-agnostic. There is now a separate internal class,
_TextInputChannelConnection, that implements the default type of text
input connection that communicates with platform plugins via the text
input system channel.

The main motivation of the separation is to allow custom text input
sources that can replace the method channel-based implementation and
for example, communicate with an in-app virtual keyboard on (embedded)
platforms that do not have a keyboard provided by the system

Ref: flutter#68988
jpnurmi added a commit to jpnurmi/flutter that referenced this issue Jan 15, 2021
@Im-Kevin
Copy link
Contributor

You can consider Cool_UI

@LongCatIsLooong LongCatIsLooong added P1 High-priority issues at the top of the work list customer: dream (g3) labels May 13, 2021
@LongCatIsLooong
Copy link
Contributor

LongCatIsLooong commented May 13, 2021

An internal customer has requested this feature. It is not blocking but they would like to switch to using a virtual in-flutter keyboard when it's ready.

@jpnurmi
Copy link
Member Author

jpnurmi commented May 13, 2021

@LongCatIsLooong Does the implementation look good in general? Is there anything else needed besides thorough testing on all platforms?

@LongCatIsLooong
Copy link
Contributor

@jpnurmi yeah I think it looks good to me in general (thank you very much for the effort you put in the PR!), but I'd like to grab a second pair of eyes from the web team and verify this does not break the current web implementation.

@github-actions
Copy link

This thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new bug, including the output of flutter doctor -v and a minimal reproduction of the issue.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Oct 18, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
a: text input Entering text in a text field or keyboard related problems c: proposal A detailed proposal for a change to Flutter customer: dream (g3) framework flutter/packages/flutter repository. See also f: labels. P1 High-priority issues at the top of the work list
Projects
None yet
5 participants