Status Update
Comments
se...@google.com <se...@google.com>
si...@google.com <si...@google.com> #2
Branch: androidx-master-dev
commit c60f33e229e31ab328ef6b59dab63b264954831c
Author: Alexandre Elias <aelias@google.com>
Date: Fri Jul 10 16:23:09 2020
Semantics no-op cleanups
Partly in response to lmr's broad code review, I did a pass of
superficial API/implementation cleanup. The main changes are:
- I changed each Boolean SemanticsProperty where false is equivalent to
not being present to take "Unit" instead. This is conceptually
clearer: it avoids questions like "can I cancel out a semantics from a
merged child by setting it to false?" Because "property = Unit" looks
weird, I also changed the style of these to "property()".
- I moved the Semantics id generator closer to where it's used, in
SemanticsModifierCore. I made it internal and an AtomicInt.
(Note that integer ids are heavily used in the Android
AccessibilityNodeInfo APIs so I can't simply remove them entirely.)
- I deleted dead code. Some examples include SemanticsHintOverrides,
a public API not connected to anything, and SemanticsPropertyKey
merge() open method which is never called. (In both cases I have
a different plan in mind for accessibility.)
Fixes: 145951226
Fixes: 145955412
Test: existing tests
Relnote: "Single-value semantics properties now use a calling style.
For example, 'semantics { hidden = true }' is now written as:
'semantics { hidden() }'."
Change-Id: Ic1afd12ea22c926babc9662f1804d80b33aa0cfc
M ui/integration-tests/benchmark/src/androidTest/java/androidx/ui/benchmark/test/LayoutNodeModifierBenchmark.kt
M ui/ui-core/api/0.1.0-dev15.txt
M ui/ui-core/api/current.txt
M ui/ui-core/api/public_plus_experimental_0.1.0-dev15.txt
M ui/ui-core/api/public_plus_experimental_current.txt
M ui/ui-core/api/restricted_0.1.0-dev15.txt
M ui/ui-core/api/restricted_current.txt
M ui/ui-core/src/androidAndroidTest/kotlin/androidx/ui/graphics/vector/VectorTest.kt
M ui/ui-core/src/androidAndroidTest/kotlin/androidx/ui/semantics/SemanticsTests.kt
M ui/ui-core/src/androidMain/kotlin/androidx/ui/core/AndroidActuals.kt
M ui/ui-core/src/androidMain/kotlin/androidx/ui/core/AndroidComposeView.kt
M ui/ui-core/src/androidMain/kotlin/androidx/ui/core/AndroidComposeViewAccessibilityDelegateCompat.kt
M ui/ui-core/src/androidMain/kotlin/androidx/ui/core/AndroidPopup.kt
M ui/ui-core/src/commonMain/kotlin/androidx/ui/core/Expect.kt
M ui/ui-core/src/commonMain/kotlin/androidx/ui/core/semantics/SemanticsConfiguration.kt
D ui/ui-core/src/commonMain/kotlin/androidx/ui/core/semantics/SemanticsHintOverrides.kt
M ui/ui-core/src/commonMain/kotlin/androidx/ui/core/semantics/SemanticsModifier.kt
M ui/ui-core/src/commonMain/kotlin/androidx/ui/core/semantics/SemanticsNode.kt
M ui/ui-core/src/commonMain/kotlin/androidx/ui/core/semantics/SemanticsOwner.kt
M ui/ui-core/src/commonMain/kotlin/androidx/ui/core/semantics/SemanticsWrapper.kt
M ui/ui-core/src/commonMain/kotlin/androidx/ui/semantics/SemanticsProperties.kt
M ui/ui-foundation/api/0.1.0-dev15.txt
M ui/ui-foundation/api/current.txt
M ui/ui-foundation/api/public_plus_experimental_0.1.0-dev15.txt
M ui/ui-foundation/api/public_plus_experimental_current.txt
M ui/ui-foundation/api/restricted_0.1.0-dev15.txt
M ui/ui-foundation/api/restricted_current.txt
M ui/ui-foundation/src/main/java/androidx/ui/foundation/Clickable.kt
M ui/ui-foundation/src/main/java/androidx/ui/foundation/Dialog.kt
M ui/ui-foundation/src/main/java/androidx/ui/foundation/Scroller.kt
M ui/ui-foundation/src/main/java/androidx/ui/foundation/selection/Selectable.kt
M ui/ui-foundation/src/main/java/androidx/ui/foundation/selection/Toggleable.kt
M ui/ui-foundation/src/main/java/androidx/ui/foundation/semantics/FoundationSemanticsProperties.kt
M ui/ui-material/src/androidTest/java/androidx/ui/material/ButtonTest.kt
M ui/ui-material/src/androidTest/java/androidx/ui/material/CardTest.kt
M ui/ui-material/src/androidTest/java/androidx/ui/material/CheckboxScreenshotTest.kt
M ui/ui-material/src/androidTest/java/androidx/ui/material/RadioButtonScreenshotTest.kt
M ui/ui-material/src/androidTest/java/androidx/ui/material/ScaffoldTest.kt
M ui/ui-material/src/androidTest/java/androidx/ui/material/SnackbarTest.kt
M ui/ui-material/src/androidTest/java/androidx/ui/material/SurfaceTest.kt
M ui/ui-material/src/androidTest/java/androidx/ui/material/ripple/RippleIndicationTest.kt
M ui/ui-material/src/androidTest/java/androidx/ui/material/textfield/TextFieldScreenshotTest.kt
M ui/ui-material/src/main/java/androidx/ui/material/AppBar.kt
M ui/ui-material/src/main/java/androidx/ui/material/TextFieldImpl.kt
M ui/ui-test/src/androidTest/java/androidx/ui/test/AssertsTest.kt
M ui/ui-test/src/androidTest/java/androidx/ui/test/CallSemanticsActionTest.kt
M ui/ui-test/src/androidTest/java/androidx/ui/test/ErrorMessagesTest.kt
M ui/ui-test/src/androidTest/java/androidx/ui/test/FindersTest.kt
M ui/ui-test/src/androidTest/java/androidx/ui/test/PrintToStringTest.kt
M ui/ui-test/src/androidTest/java/androidx/ui/test/ScrollToTest.kt
M ui/ui-test/src/androidTest/java/androidx/ui/test/TextActionsTest.kt
M ui/ui-test/src/main/java/androidx/ui/test/Actions.kt
M ui/ui-test/src/main/java/androidx/ui/test/Filters.kt
M ui/ui-text/api/0.1.0-dev15.txt
M ui/ui-text/api/current.txt
M ui/ui-text/api/public_plus_experimental_0.1.0-dev15.txt
M ui/ui-text/api/public_plus_experimental_current.txt
M ui/ui-text/api/restricted_0.1.0-dev15.txt
M ui/ui-text/api/restricted_current.txt
M ui/ui-text/src/commonMain/kotlin/androidx/ui/text/CoreTextField.kt
M ui/ui-text/src/commonMain/kotlin/androidx/ui/text/TextSemanticsProperties.kt
so...@google.com <so...@google.com> #3
I had a bug somewhere back then to implement this in material text fields. Now that we have a decoration box API, I think it's a good idea to make it for all text fields.
I'm wondering how it will behave if you have a textfield taking up the whole screen (like Notes app). Will it scroll anyway? Especially if windowSoftInputMode
defined per activity, and you have two text fields in one activity (one small and the other one taking most of the screen).
si...@google.com <si...@google.com> #4
I'm wondering how it will behave if you have a textfield taking up the whole screen (like Notes app). Will it scroll anyway?
It would depend on scrolling implementation we will implement (as far as I know we still didn't). I don't see a reason why it wouldn't scroll to the correct place (if the label does not take too much space).
One issue is showing the cursor. If we send the whole box, and if the TextField is too long (lets say 100 lines), then sending the whole box means that the cursor might not show up.
Maybe it is something we should take into account while implementing i.e. sending 2 rectangles:
- 1 for the box
- 1 for the cursor
- we try to show the box as a whole but we also try to make sure the cursor rectangle is visible (which means if the Textfield is 2 pages long, and the cursor is at the end, we lean towards the bottom half of the box; or if the cursor is at the begining we lean towards the top half of the box.
- this might be an edge case that we can check later as well.
I couldn't know the exact/correct answer right now :/
si...@google.com <si...@google.com> #5
might be a P3 as well. I wanted to remove P4 since this is in our current list of tasks to do.
ni...@google.com <ni...@google.com> #6
Bulk edit: This bug is currently marked as blocking Compose 1.0. Once rc01 is cut, all changes will need to go through our cherry-pick process.
If you intend to fix it in Compose 1.0, no action is needed except prioritizing finishing this work.
Otherwise, please remove this bug from the appropriate 1.0 hotlist (likely
Thanks!
so...@google.com <so...@google.com> #7
Played a bit with one of the ideas: if the line being edited is not the last one, leave current behavior (i.e. show the cursor); otherwise use the decoration box bounds. In that case single line text field will always display padding/decoration box. In multi-line text field (Notes like app for example) we won't show the decoration box if not the last line is being edited.
Alternatively, I want to consider another option where we show the cursor and a bit more. I'll add more details when I played more with the idea.
We might need a UX input here.
Another point is that we need to make sure we request rectangle after editing, as currently we only do this on initial focus. As a result, when user types, the cursor becomes hidden behind the keyboard anyway.
so...@google.com <so...@google.com> #8
Zach, this one is fixed, isn't it? Probably can be marked as duplicate
kl...@google.com <kl...@google.com> #9
This isn't working yet because of bringIntoView
call it works as expected.
ap...@google.com <ap...@google.com> #10
Branch: androidx-main
commit 04501ae82a6f8349c5a4037080bb2b93c7fddefe
Author: Zach Klippenstein <klippenstein@google.com>
Date: Fri Apr 15 15:26:57 2022
Ignore bringIntoView requests that are already satisfied by an in-progress request.
If a new bringIntoView call happens before the previous one is finished,
then if the new one requests a rectangle that will already be in
view after the old request is satisfied, the new request is ignored.
Bug:
Fixes:
Test: New tests for BringIntoViewResponder and text field.
Test: ./gradlew :compose:f:f:cDAT
Relnote: "Concurrent `BringIntoViewRequester.bringIntoView` calls for
rectangles that are completely overlapping will now only honor the
larger rectangle's request."
Change-Id: I34be70f23527e4fea694fd5266bbc127cc1d1b0b
M compose/foundation/foundation/src/androidAndroidTest/kotlin/androidx/compose/foundation/textfield/TextFieldFocusTest.kt
M compose/foundation/foundation/src/commonMain/kotlin/androidx/compose/foundation/relocation/BringIntoViewRequester.kt
M compose/foundation/foundation/integration-tests/foundation-demos/src/main/java/androidx/compose/foundation/demos/text/TextFieldsInScrollableDemo.kt
M compose/foundation/foundation/src/androidAndroidTest/kotlin/androidx/compose/foundation/relocation/BringIntoViewResponderTest.kt
M compose/foundation/foundation/src/commonMain/kotlin/androidx/compose/foundation/relocation/BringIntoViewResponder.kt
Description
If the software keyboard comes into view, decorationBox of BasicTextField gets ignored. The keyboard appears --> the content scrolls up, but only until the TextFields input area. It does not observe the extra padding provided by the decorationBox.