Fixed
Status Update
Comments
da...@well.co <da...@well.co> #2
Project: platform/frameworks/support
Branch: androidx-main
commit a330c0d3bcdd41326f37968a60e6084ad4a2e32c
Author: Chet Haase <chet@google.com>
Date: Wed Jul 05 07:26:46 2023
Convert APIs using PointF to use Float instead
PointF is a convenient mechanism for passing around x.y values
representing 2D points. But there are downsides, including:
- Converting to PointF: You may not have the data in PointF form
to begin with, so using an API which takes PointF requires converting
the data to that form (including allocating a PointF object every time)
- Mutability: Point structures can be mutated internally, causing
unpredictability in what that mutation means. Should the library
react to those changes? Ignore them? Do defensive copies (requiring
even more allocations)? Using primitive types like Float make the
behavior more obvious (by making the data inherently immutable).
- Allocations: Whenever we use object types, there are necessarily
allocations on the Java heap for them. This puts pressure on the GC
at both allocation and collection time. Given the amount of points
being passed around (especially at morph creation time, when curves
are being split and created), this causes a lot of PointF objects to
be allocated (even temporarily). Using Float avoids that problem.
Also fixed bug with unclosed paths causing discontinuity at the
start/end point.
Bug: 276466399
Bug: 290254314
Test: integration and unit tests pass
Relnote: PointF parameters changed to Float pairs
Change-Id: Id4705d27c7be31b26ade8186b99fffe2e2f8450e
M graphics/graphics-shapes/api/current.txt
M graphics/graphics-shapes/api/restricted_current.txt
M graphics/graphics-shapes/src/androidTest/java/androidx/graphics/shapes/CubicShapeTest.kt
M graphics/graphics-shapes/src/androidTest/java/androidx/graphics/shapes/CubicTest.kt
M graphics/graphics-shapes/src/androidTest/java/androidx/graphics/shapes/PolygonMeasureTest.kt
M graphics/graphics-shapes/src/androidTest/java/androidx/graphics/shapes/PolygonTest.kt
M graphics/graphics-shapes/src/androidTest/java/androidx/graphics/shapes/RoundedPolygonTest.kt
M graphics/graphics-shapes/src/androidTest/java/androidx/graphics/shapes/ShapesTest.kt
M graphics/graphics-shapes/src/androidTest/java/androidx/graphics/shapes/TestUtils.kt
M graphics/graphics-shapes/src/main/java/androidx/graphics/shapes/Cubic.kt
M graphics/graphics-shapes/src/main/java/androidx/graphics/shapes/CubicShape.kt
M graphics/graphics-shapes/src/main/java/androidx/graphics/shapes/FeatureMapping.kt
M graphics/graphics-shapes/src/main/java/androidx/graphics/shapes/FloatMapping.kt
M graphics/graphics-shapes/src/main/java/androidx/graphics/shapes/Morph.kt
M graphics/graphics-shapes/src/main/java/androidx/graphics/shapes/PolygonMeasure.kt
M graphics/graphics-shapes/src/main/java/androidx/graphics/shapes/RoundedPolygon.kt
M graphics/graphics-shapes/src/main/java/androidx/graphics/shapes/Shapes.kt
M graphics/graphics-shapes/src/main/java/androidx/graphics/shapes/Utils.kt
M graphics/integration-tests/testapp-compose/src/main/java/androidx/graphics/shapes/testcompose/DebugDraw.kt
M graphics/integration-tests/testapp-compose/src/main/java/androidx/graphics/shapes/testcompose/ShapeEditor.kt
M graphics/integration-tests/testapp/src/main/java/androidx/graphics/shapes/test/MaterialShapes.kt
https://android-review.googlesource.com/2649119
Branch: androidx-main
commit a330c0d3bcdd41326f37968a60e6084ad4a2e32c
Author: Chet Haase <chet@google.com>
Date: Wed Jul 05 07:26:46 2023
Convert APIs using PointF to use Float instead
PointF is a convenient mechanism for passing around x.y values
representing 2D points. But there are downsides, including:
- Converting to PointF: You may not have the data in PointF form
to begin with, so using an API which takes PointF requires converting
the data to that form (including allocating a PointF object every time)
- Mutability: Point structures can be mutated internally, causing
unpredictability in what that mutation means. Should the library
react to those changes? Ignore them? Do defensive copies (requiring
even more allocations)? Using primitive types like Float make the
behavior more obvious (by making the data inherently immutable).
- Allocations: Whenever we use object types, there are necessarily
allocations on the Java heap for them. This puts pressure on the GC
at both allocation and collection time. Given the amount of points
being passed around (especially at morph creation time, when curves
are being split and created), this causes a lot of PointF objects to
be allocated (even temporarily). Using Float avoids that problem.
Also fixed bug with unclosed paths causing discontinuity at the
start/end point.
Bug: 276466399
Bug: 290254314
Test: integration and unit tests pass
Relnote: PointF parameters changed to Float pairs
Change-Id: Id4705d27c7be31b26ade8186b99fffe2e2f8450e
M graphics/graphics-shapes/api/current.txt
M graphics/graphics-shapes/api/restricted_current.txt
M graphics/graphics-shapes/src/androidTest/java/androidx/graphics/shapes/CubicShapeTest.kt
M graphics/graphics-shapes/src/androidTest/java/androidx/graphics/shapes/CubicTest.kt
M graphics/graphics-shapes/src/androidTest/java/androidx/graphics/shapes/PolygonMeasureTest.kt
M graphics/graphics-shapes/src/androidTest/java/androidx/graphics/shapes/PolygonTest.kt
M graphics/graphics-shapes/src/androidTest/java/androidx/graphics/shapes/RoundedPolygonTest.kt
M graphics/graphics-shapes/src/androidTest/java/androidx/graphics/shapes/ShapesTest.kt
M graphics/graphics-shapes/src/androidTest/java/androidx/graphics/shapes/TestUtils.kt
M graphics/graphics-shapes/src/main/java/androidx/graphics/shapes/Cubic.kt
M graphics/graphics-shapes/src/main/java/androidx/graphics/shapes/CubicShape.kt
M graphics/graphics-shapes/src/main/java/androidx/graphics/shapes/FeatureMapping.kt
M graphics/graphics-shapes/src/main/java/androidx/graphics/shapes/FloatMapping.kt
M graphics/graphics-shapes/src/main/java/androidx/graphics/shapes/Morph.kt
M graphics/graphics-shapes/src/main/java/androidx/graphics/shapes/PolygonMeasure.kt
M graphics/graphics-shapes/src/main/java/androidx/graphics/shapes/RoundedPolygon.kt
M graphics/graphics-shapes/src/main/java/androidx/graphics/shapes/Shapes.kt
M graphics/graphics-shapes/src/main/java/androidx/graphics/shapes/Utils.kt
M graphics/integration-tests/testapp-compose/src/main/java/androidx/graphics/shapes/testcompose/DebugDraw.kt
M graphics/integration-tests/testapp-compose/src/main/java/androidx/graphics/shapes/testcompose/ShapeEditor.kt
M graphics/integration-tests/testapp/src/main/java/androidx/graphics/shapes/test/MaterialShapes.kt
co...@google.com <co...@google.com> #3
PointF was the main (possibly only) mutability issue, marking this as fixed
da...@well.co <da...@well.co> #4
The following release(s) address this bug.It is possible this bug has only been partially addressed:
androidx.graphics:graphics-shapes:1.0.0-alpha04
ya...@well.co <ya...@well.co> #5
Do we have any update here ? this issue still exists in Material 3 upgrade.
ya...@well.co <ya...@well.co> #6
Even the M3 ExposedDropDownBox does not match ADA of ViewSystem, In ViewSystem ExposedDropDown Style announcing as "[Selected Option] Drop Down List [Label] Double tap to change", compared to M3 ExposedDropDown "[SELECTION] EditBox drop down menu [Drop Down Label]. Double tap and hold to to long press. Actions available use tap with 3 fingers to view."
da...@gmail.com <da...@gmail.com> #7
dependencies { implementation "androidx.compose.material:material:1.5.4" }
android { buildFeatures { compose true }
composeOptions {
kotlinCompilerExtensionVersion = "1.5.3"
}
kotlinOptions {
jvmTarget = "1.8"
}
}
ap...@google.com <ap...@google.com> #8
Project: platform/frameworks/support
Branch: androidx-main
commit b01be1f0984e1ae035582524be989edc14b83b42
Author: Max Alfonso-Ying <maxying@google.com>
Date: Fri Apr 05 00:22:27 2024
Improve a11y of editable ExposedDropdownMenus
Updated `Modifier.menuAnchor` to support icons in addition
to text fields. Now takes a parameter for MenuAnchorType
so we can set popup flags accordingly. Also added an enabled
parameter to control if the anchor is enabled.
This means editable EDMs can use 2 menu anchors to
support both flows of typing and direct selection when
a11y services are enabled.
Updated sample to show this usage.
Fixes: b/257209915 , b/308840226
Test: Added unit tests for enabled/disabled menuAnchor. Manual testing with TalkBack
Relnote: "`ExposedDropdownMenuBoxScope` no longer permits subclasses.
Exposed dropdown menus now have a `MenuAnchorType` which
should be passed to `menuAnchor` to support better a11y.
This should be used instead of passing `focusable` to
`ExposedDropdownMenu`, which is now deprecated.
`menuAnchor` has a new parameter to control `enabled` state."
Change-Id: I55ee632daf66ef4df90297350cbff901e26ea446
M compose/material3/benchmark/src/androidTest/java/androidx/compose/material3/benchmark/ExposedDropdownMenuBenchmark.kt
M compose/material3/material3/api/current.txt
M compose/material3/material3/api/restricted_current.txt
M compose/material3/material3/samples/src/main/java/androidx/compose/material3/samples/ExposedDropdownMenuSamples.kt
M compose/material3/material3/src/androidInstrumentedTest/kotlin/androidx/compose/material3/ExposedDropdownMenuTest.kt
M compose/material3/material3/src/androidMain/kotlin/androidx/compose/material3/ExposedDropdownMenu.android.kt
M compose/material3/material3/src/androidMain/kotlin/androidx/compose/material3/internal/Strings.android.kt
M compose/material3/material3/src/androidMain/res/values/strings.xml
M compose/material3/material3/src/commonMain/kotlin/androidx/compose/material3/internal/Strings.kt
M compose/material3/material3/src/desktopMain/kotlin/androidx/compose/material3/internal/Strings.desktop.kt
https://android-review.googlesource.com/3028145
Branch: androidx-main
commit b01be1f0984e1ae035582524be989edc14b83b42
Author: Max Alfonso-Ying <maxying@google.com>
Date: Fri Apr 05 00:22:27 2024
Improve a11y of editable ExposedDropdownMenus
Updated `Modifier.menuAnchor` to support icons in addition
to text fields. Now takes a parameter for MenuAnchorType
so we can set popup flags accordingly. Also added an enabled
parameter to control if the anchor is enabled.
This means editable EDMs can use 2 menu anchors to
support both flows of typing and direct selection when
a11y services are enabled.
Updated sample to show this usage.
Fixes:
Test: Added unit tests for enabled/disabled menuAnchor. Manual testing with TalkBack
Relnote: "`ExposedDropdownMenuBoxScope` no longer permits subclasses.
Exposed dropdown menus now have a `MenuAnchorType` which
should be passed to `menuAnchor` to support better a11y.
This should be used instead of passing `focusable` to
`ExposedDropdownMenu`, which is now deprecated.
`menuAnchor` has a new parameter to control `enabled` state."
Change-Id: I55ee632daf66ef4df90297350cbff901e26ea446
M compose/material3/benchmark/src/androidTest/java/androidx/compose/material3/benchmark/ExposedDropdownMenuBenchmark.kt
M compose/material3/material3/api/current.txt
M compose/material3/material3/api/restricted_current.txt
M compose/material3/material3/samples/src/main/java/androidx/compose/material3/samples/ExposedDropdownMenuSamples.kt
M compose/material3/material3/src/androidInstrumentedTest/kotlin/androidx/compose/material3/ExposedDropdownMenuTest.kt
M compose/material3/material3/src/androidMain/kotlin/androidx/compose/material3/ExposedDropdownMenu.android.kt
M compose/material3/material3/src/androidMain/kotlin/androidx/compose/material3/internal/Strings.android.kt
M compose/material3/material3/src/androidMain/res/values/strings.xml
M compose/material3/material3/src/commonMain/kotlin/androidx/compose/material3/internal/Strings.kt
M compose/material3/material3/src/desktopMain/kotlin/androidx/compose/material3/internal/Strings.desktop.kt
na...@google.com <na...@google.com> #9
The following release(s) address this bug.It is possible this bug has only been partially addressed:
androidx.compose.material3:material3:1.3.0-alpha05
androidx.compose.material3:material3-android:1.3.0-alpha05
androidx.compose.material3:material3-desktop:1.3.0-alpha05
Description
Jetpack Compose version: 1.3.0 Jetpack Compose component used: ExposedDropdownMenuBox,TextField Android Studio Build: 2022.1.1 Canary 2 Kotlin version: 1.7.10
How the layout system would read a dropdown
Which the above is pretty reasonable
Compose for the same situation and configuration reads:
So there is multiple things wrong above. I am not saying it needs to be the same as layout system but the same or better.
Also if you look at second 0:40-0:50 you will see it reads out the drop down and edit box separately. This is not working like a user would expect.
This is a really bad UX and I think the only reasonable work around is to use the layout system for all drop downs.
Appreciate you looking into this ADA issue.