STOP MAKING ALL USEFUL APIS INTERNAL [229839039]

Duplicate

of 163132293

Bug

Status Update

No update yet.

Description

bl...@gmail.com

created issue #1

Apr 21, 2022 11:47AM

PLEASE STOP MAKING ALL USEFUL APIS INTERNAL

When Compose was released, it was accompanied with confident gloating about how it was easy to mix and match components with different granularity on the UI layers. One aspect of this was that many implementation APIs are accessible to developers. To my horror, more and more APIs are marked internal in the Material 3 library. For example, all the SwipeableState APIs (i.e. rememberSwipeableState and all associated classes / functions) are now internal, while they were public in Material 2. This forces me to copy-paste the exact library code for swipe state into my own project, just so I can get a reference to the swipeable state, and this seems kind of idiotic to me.

PLEASE STOP MAKING ALL USEFUL APIS INTERNAL

Jetpack Compose component used: androidx.compose.material3:material3:1.0.0-alpha10

Steps to Reproduce or Code Sample to Reproduce:

Try to migrate from M2 to M3
Give up because it's a total mess

Comments

jo...@google.com <jo...@google.com> #2Apr 25, 2022 09:43AM

Status: Duplicate of

163132293

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.

bl...@gmail.com <bl...@gmail.com> #3Apr 25, 2022 09:16PM

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.

bl...@gmail.com <bl...@gmail.com> #4May 19, 2022 01:25PM

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).

jo...@google.com <jo...@google.com> #5May 19, 2022 01:31PM

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.

bl...@gmail.com <bl...@gmail.com> #6May 19, 2022 03:48PM

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."

bl...@gmail.com <bl...@gmail.com> #7May 23, 2022 10:27PM

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

b/123001228#comment6

video5215400932384187196.mp4

609 KB

Download

bl...@gmail.com <bl...@gmail.com> #8Aug 24, 2022 08:17PM

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.

ni...@google.com <ni...@google.com> #9Nov 4, 2022 07:01PM

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.

to...@gmail.com <to...@gmail.com> #10Mar 28, 2023 04:21AM

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

jo...@gmail.com <jo...@gmail.com> #11Mar 29, 2023 11:47PM

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

sy...@gmail.com <sy...@gmail.com> #12Jul 28, 2023 05:06PM

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.

jo...@google.com <jo...@google.com> #13Jul 31, 2023 08:38AM

One more thing. Cursor animation should be disabled during cursor navigation. Currently, the cursor is blinking as usual.