Infeasible
Status Update
No update yet.
Comments
ri...@gmail.com
I don't think this falls under pointer input so this is simply less tied to the area I've been focusing on. I think this should be considered open for anyone else to start working on. I think the two main areas of work for keyboard input are building out the equivalent of focusableInTouchMode and routing keyboard input events to the appropriate node/modifier.
Is this something that Semantics should handle? Seems that if it did, both keyboard events, auto fill, google assistant, could all use the same mechanism to send text data to the ui.
Is this something that Semantics should handle? Seems that if it did, both keyboard events, auto fill, google assistant, could all use the same mechanism to send text data to the ui.
pa...@google.com
Hey Shep, thanks for the info.
For the ticket itself it is a reminder for us that is not prioritized yet.
For editable text (TextField) this should already work since IME handles it.
However I am not sure if and when we want to support what Android has (things like menu shortcuts).
Happy to hear from Ryan and Ralston in case this subject was discussed before.
For the ticket itself it is a reminder for us that is not prioritized yet.
For editable text (TextField) this should already work since IME handles it.
However I am not sure if and when we want to support what Android has (things like menu shortcuts).
Happy to hear from Ryan and Ralston in case this subject was discussed before.
ni...@google.com
I don't think this is/should be within Semantics's domain. Hardware keyboard input should, as far as I know, follow the same path as (and is, as far as I understand it, indistinguishable from) soft keyboard input (in fact, Gboard actually interacts with hardware keyboards).
I also don't think we want autofill/assistant to actually send keyboard events. That could lead to very strange results as well as maybe performance issues - consider it trying to send dozens of key events instantaneously. I'd think we'd want it to fill text fields directly via some other mechanism (probably an action callback).
I also don't think we want autofill/assistant to actually send keyboard events. That could lead to very strange results as well as maybe performance issues - consider it trying to send dozens of key events instantaneously. I'd think we'd want it to fill text fields directly via some other mechanism (probably an action callback).
po...@google.com
ci...@google.com
Ah, I based on Siyamed's comment, this bug is intended to track the work necessary to handle keyboard events that aren't related to IME. (like menu shortcuts). I'm not sure what is needed here.
pa...@google.com
le...@gmail.com
Oh I see. There's probably some overlap there. For instance, the accessibility focus traversal ordering is probably pretty similar to the input focus traversal ordering (though a11y would likely focus things that input would not).
I think one question is probably at what level these things live. There are a bunch of keys that probably don't need to go to substantially all widgets with keyboard input, like volume/menu/search/back. Then there are things like tab, which some input widgets will want, but others should ignore and pass through to another handler (to, say, move input focus).
I think Android's model for this is pretty decent - an intercept pass down the hierachy, then a pass back up for normal handling. It handles both cases well, as each component can decide which keys it cares about, rather than us trying to predict all use-cases in advance. We would, of course, handle these correctly in our controls, and we'd need to make it easy (no internals or copy-pasting of internals) to implement, say, correct tab behavior.
All of which is a long-winded way of saying: "I think we should handle these like any other keyboard input."
I think one question is probably at what level these things live. There are a bunch of keys that probably don't need to go to substantially all widgets with keyboard input, like volume/menu/search/back. Then there are things like tab, which some input widgets will want, but others should ignore and pass through to another handler (to, say, move input focus).
I think Android's model for this is pretty decent - an intercept pass down the hierachy, then a pass back up for normal handling. It handles both cases well, as each component can decide which keys it cares about, rather than us trying to predict all use-cases in advance. We would, of course, handle these correctly in our controls, and we'd need to make it easy (no internals or copy-pasting of internals) to implement, say, correct tab behavior.
All of which is a long-winded way of saying: "I think we should handle these like any other keyboard input."
zu...@tutu.tech
bulk comment, fyi: we have added icebox to all the tickets because it was suggested by blintz in order to prevent auto-close tickets. we want to keep our Compose tickets to remain opened.
see
see
lo...@gmail.com
Looks like there is currently a ticket assigned to Ralston. Will keep this ticket active for testing as well. Ralston feel free to dup this ticket, or we can use it as a reminder to test.
lp...@google.com
Let's keep this ticket open. I can see that it is already marked as blocked by the keyboard Input ticket that I am working on right now.
ak...@gmail.com
Project: platform/frameworks/support
Branch: androidx-main
commit 072a880c9ab1a245711fe9e67e9a56f2da04b790
Author: Andrey Rudenko <andrei.rudenko@jetbrains.com>
Date: Fri Feb 05 22:43:02 2021
Hardware Keyboard support in TextField
It adds onKeyEvent Modifier to CoreTextField and sets up the handling of KeyEvent in a uniform way across Android and Desktop. This includes support of all main keyboard shortcuts to edit, navigate and select text in TextField.
This CL doesn't touch any of the existing APIs and doesn't introduce the new ones. On Desktop in changes significantly how hardware keyboard events are handled. PlatformInput is responsible only for interaction with IM.
Most of the text operations in this CL were abstracted to TextFieldPreparedSelection and TextPreparedSelection, the latter one can be used in future CL to implement similar keyboard shortcuts for CoreText.
It's incomplete, we have to define better the Compose behavior on Android with a hardware keyboard, possibly it has to react to TouchMode changes and, for example, do not show software keyboard when hardware one is in action
Relnote: N/A
Bug: 139322105
Test: ./gradlew :compose:foundation:foundation:connectedAndroidTest
Change-Id: I2d5d462ec1f57de41ddfd9218411e695fe4bb2e2
M compose/desktop/desktop/samples/src/jvmMain/kotlin/androidx/compose/desktop/examples/example1/Main.jvm.kt
M compose/foundation/foundation/api/1.0.0-beta02.txt
M compose/foundation/foundation/api/current.txt
M compose/foundation/foundation/api/public_plus_experimental_1.0.0-beta02.txt
M compose/foundation/foundation/api/public_plus_experimental_current.txt
M compose/foundation/foundation/api/restricted_1.0.0-beta02.txt
M compose/foundation/foundation/api/restricted_current.txt
M compose/foundation/foundation/build.gradle
A compose/foundation/foundation/src/androidAndroidTest/kotlin/androidx/compose/foundation/textfield/HardwareKeyboardTest.kt
M compose/foundation/foundation/src/androidMain/kotlin/androidx/compose/foundation/text/KeyMapping.android.kt
M compose/foundation/foundation/src/androidMain/kotlin/androidx/compose/foundation/text/TextFieldKeyInput.android.kt
M compose/foundation/foundation/src/commonMain/kotlin/androidx/compose/foundation/text/CoreTextField.kt
A compose/foundation/foundation/src/commonMain/kotlin/androidx/compose/foundation/text/KeyCommand.kt
A compose/foundation/foundation/src/commonMain/kotlin/androidx/compose/foundation/text/KeyMapping.kt
M compose/foundation/foundation/src/commonMain/kotlin/androidx/compose/foundation/text/StringHelpers.kt
A compose/foundation/foundation/src/commonMain/kotlin/androidx/compose/foundation/text/TextFieldKeyInput.kt
A compose/foundation/foundation/src/commonMain/kotlin/androidx/compose/foundation/text/selection/TextPreparedSelection.kt
M compose/foundation/foundation/src/desktopMain/kotlin/androidx/compose/foundation/text/DesktopCoreTextField.desktop.kt
A compose/foundation/foundation/src/desktopMain/kotlin/androidx/compose/foundation/text/KeyMapping.desktop.kt
A compose/foundation/foundation/src/desktopMain/kotlin/androidx/compose/foundation/text/TextFieldKeyInput.desktop.kt
A compose/foundation/foundation/src/jvmMain/kotlin/androidx/compose/foundation/text/StringHelpers.jvm.kt
M compose/ui/ui-text/src/desktopMain/kotlin/androidx/compose/ui/text/platform/DesktopParagraph.desktop.kt
M compose/ui/ui-text/src/desktopTest/kotlin/androidx/compose/ui/text/DesktopParagraphTest.kt
M compose/ui/ui/src/desktopMain/kotlin/androidx/compose/desktop/ComposeLayer.desktop.kt
M compose/ui/ui/src/desktopMain/kotlin/androidx/compose/ui/input/key/Key.desktop.kt
M compose/ui/ui/src/desktopMain/kotlin/androidx/compose/ui/platform/DesktopOwner.desktop.kt
M compose/ui/ui/src/desktopMain/kotlin/androidx/compose/ui/platform/DesktopOwners.desktop.kt
M compose/ui/ui/src/desktopMain/kotlin/androidx/compose/ui/platform/DesktopPlatformInput.desktop.kt
https://android-review.googlesource.com/1578803
Branch: androidx-main
commit 072a880c9ab1a245711fe9e67e9a56f2da04b790
Author: Andrey Rudenko <andrei.rudenko@jetbrains.com>
Date: Fri Feb 05 22:43:02 2021
Hardware Keyboard support in TextField
It adds onKeyEvent Modifier to CoreTextField and sets up the handling of KeyEvent in a uniform way across Android and Desktop. This includes support of all main keyboard shortcuts to edit, navigate and select text in TextField.
This CL doesn't touch any of the existing APIs and doesn't introduce the new ones. On Desktop in changes significantly how hardware keyboard events are handled. PlatformInput is responsible only for interaction with IM.
Most of the text operations in this CL were abstracted to TextFieldPreparedSelection and TextPreparedSelection, the latter one can be used in future CL to implement similar keyboard shortcuts for CoreText.
It's incomplete, we have to define better the Compose behavior on Android with a hardware keyboard, possibly it has to react to TouchMode changes and, for example, do not show software keyboard when hardware one is in action
Relnote: N/A
Bug: 139322105
Test: ./gradlew :compose:foundation:foundation:connectedAndroidTest
Change-Id: I2d5d462ec1f57de41ddfd9218411e695fe4bb2e2
M compose/desktop/desktop/samples/src/jvmMain/kotlin/androidx/compose/desktop/examples/example1/Main.jvm.kt
M compose/foundation/foundation/api/1.0.0-beta02.txt
M compose/foundation/foundation/api/current.txt
M compose/foundation/foundation/api/public_plus_experimental_1.0.0-beta02.txt
M compose/foundation/foundation/api/public_plus_experimental_current.txt
M compose/foundation/foundation/api/restricted_1.0.0-beta02.txt
M compose/foundation/foundation/api/restricted_current.txt
M compose/foundation/foundation/build.gradle
A compose/foundation/foundation/src/androidAndroidTest/kotlin/androidx/compose/foundation/textfield/HardwareKeyboardTest.kt
M compose/foundation/foundation/src/androidMain/kotlin/androidx/compose/foundation/text/KeyMapping.android.kt
M compose/foundation/foundation/src/androidMain/kotlin/androidx/compose/foundation/text/TextFieldKeyInput.android.kt
M compose/foundation/foundation/src/commonMain/kotlin/androidx/compose/foundation/text/CoreTextField.kt
A compose/foundation/foundation/src/commonMain/kotlin/androidx/compose/foundation/text/KeyCommand.kt
A compose/foundation/foundation/src/commonMain/kotlin/androidx/compose/foundation/text/KeyMapping.kt
M compose/foundation/foundation/src/commonMain/kotlin/androidx/compose/foundation/text/StringHelpers.kt
A compose/foundation/foundation/src/commonMain/kotlin/androidx/compose/foundation/text/TextFieldKeyInput.kt
A compose/foundation/foundation/src/commonMain/kotlin/androidx/compose/foundation/text/selection/TextPreparedSelection.kt
M compose/foundation/foundation/src/desktopMain/kotlin/androidx/compose/foundation/text/DesktopCoreTextField.desktop.kt
A compose/foundation/foundation/src/desktopMain/kotlin/androidx/compose/foundation/text/KeyMapping.desktop.kt
A compose/foundation/foundation/src/desktopMain/kotlin/androidx/compose/foundation/text/TextFieldKeyInput.desktop.kt
A compose/foundation/foundation/src/jvmMain/kotlin/androidx/compose/foundation/text/StringHelpers.jvm.kt
M compose/ui/ui-text/src/desktopMain/kotlin/androidx/compose/ui/text/platform/DesktopParagraph.desktop.kt
M compose/ui/ui-text/src/desktopTest/kotlin/androidx/compose/ui/text/DesktopParagraphTest.kt
M compose/ui/ui/src/desktopMain/kotlin/androidx/compose/desktop/ComposeLayer.desktop.kt
M compose/ui/ui/src/desktopMain/kotlin/androidx/compose/ui/input/key/Key.desktop.kt
M compose/ui/ui/src/desktopMain/kotlin/androidx/compose/ui/platform/DesktopOwner.desktop.kt
M compose/ui/ui/src/desktopMain/kotlin/androidx/compose/ui/platform/DesktopOwners.desktop.kt
M compose/ui/ui/src/desktopMain/kotlin/androidx/compose/ui/platform/DesktopPlatformInput.desktop.kt
lp...@google.com
Andrei, can you please share with us
- overall requirements
- what is implemented
- what is to be implemented
- what are we planning in the near team to support those requirements
re...@gmail.com
Overall requirements
I can formulate some general goals:
- it should be as much "native" for the user as possible. The definition of "native" is not very clear, for desktop, for example, it differs from platform to platform, and on Linux is anarchy. On Android keyboard was some sort of a second-class citizen for a long time, as I understand, so I'm not sure how it's "native" at all for most of the users. Should we use the original text field implementation as a reference? Or Chrome one?
- full first-class rtl/bidi support
- CoreText interaction with the keyboard and especially mouse is very similar to TextField interaction, so I guess they have to share both experience and implementation, where it's possible / needed.
- exotic shortcuts like ctrl-t (emacs-like transpose) and kill-"ring" (in quotes because this "ring" is of size 1) ctrl-k/ctrl-y. Most users have no idea of them. But Chrome supports it
- undo/redo functionality
- uniformed implementation between Android and Compose for Desktop platforms
what is implemented
Adding support of key events was the easy part, thanks to the current state of focus and KeyEvent in compose. A small addition to KeyEvent interface (isTypedEvent) allowed uniform handling between Android and Desktop. Few dozens of basic keyboard commands are implemented and abstracted to the separate internal interface (TextPreparedSelection).
what is to be implemented
- rtl/bidi support is broken currently (the separate issue is here
https://partnerissuetracker.corp.google.com/u/1/issues/181900696 ) - better mouse support, at least double / triple clicks (the separate issue is here
https://partnerissuetracker.corp.google.com/u/1/issues/180639271 ) - make CoreText supports the same selection capabilities, including keyboard shortcuts
- undo/redo
what are we planning in the near term to support those requirements
Proper support of keyboard and mouse in textfield is essential for desktop experience, so we gonna continue to work on it. Everything described in "general goals" should be implemented before the beta release of CfD. With exception of "exotic shortcuts", maybe :) It would be great to hear thoughts/vision from Google, especially about Android platform.
Before the next steps I want to finish the current iteration, address some of the comments in merged CL, first of all, better test coverage, then RTL/bidi support.
I also going to write undo/redo doc, where we can discuss options that we have.
lp...@google.com
One more thing. Cursor animation should be disabled during cursor navigation. Currently, the cursor is blinking as usual.
ap...@google.com
Project: platform/frameworks/support
Branch: androidx-main
commit 8423691f9f730b9c6da33310183169ed94392101
Author: Andrey Rudenko <andrei.rudenko@jetbrains.com>
Date: Thu Mar 11 11:42:17 2021
Hardware Keyboard vertical navigation improvements and tests
To properly support navigation by lines, the logic should be stateful. It saves the x-position of the cursor when navigation was started and tries to preserve it during vertical navigation
Bug: 139322105
Test: ./gradlew :compose:foundation:foundation:connectedAndroidTest
Change-Id: Ic4daa8159146649dcc8b8982b590b700db7c8a90
A compose/foundation/foundation/src/androidAndroidTest/kotlin/androidx/compose/foundation/text/TextPreparedSelectionTest.kt
M compose/foundation/foundation/src/androidAndroidTest/kotlin/androidx/compose/foundation/textfield/HardwareKeyboardTest.kt
M compose/foundation/foundation/src/commonMain/kotlin/androidx/compose/foundation/text/TextFieldKeyInput.kt
M compose/foundation/foundation/src/commonMain/kotlin/androidx/compose/foundation/text/selection/TextPreparedSelection.kt
https://android-review.googlesource.com/1628580
Branch: androidx-main
commit 8423691f9f730b9c6da33310183169ed94392101
Author: Andrey Rudenko <andrei.rudenko@jetbrains.com>
Date: Thu Mar 11 11:42:17 2021
Hardware Keyboard vertical navigation improvements and tests
To properly support navigation by lines, the logic should be stateful. It saves the x-position of the cursor when navigation was started and tries to preserve it during vertical navigation
Bug: 139322105
Test: ./gradlew :compose:foundation:foundation:connectedAndroidTest
Change-Id: Ic4daa8159146649dcc8b8982b590b700db7c8a90
A compose/foundation/foundation/src/androidAndroidTest/kotlin/androidx/compose/foundation/text/TextPreparedSelectionTest.kt
M compose/foundation/foundation/src/androidAndroidTest/kotlin/androidx/compose/foundation/textfield/HardwareKeyboardTest.kt
M compose/foundation/foundation/src/commonMain/kotlin/androidx/compose/foundation/text/TextFieldKeyInput.kt
M compose/foundation/foundation/src/commonMain/kotlin/androidx/compose/foundation/text/selection/TextPreparedSelection.kt
Description
Currently, a dialog has a scrim around it that we get from Android's Dialog implementation. This should ideally all move to Compose, where the Android Dialog will just be a full screen panel for our Compose implementation of Dialog.
Take care of the following caveats:
The margins should be 24.dp (see