Status Update
No update yet.
Comments
al...@gmail.com
Branch: androidx-master-dev
commit 23a7d960caf43390a554700d3c56ada189a9d10e
Author: Louis Pullen-Freilich <lpf@google.com>
Date: Mon Aug 10 15:11:36 2020
IconButton / IconToggleButton API scrub
Test: ./gradlew updateApi
Bug:
Bug:
Relnote: "Adds enabled parameter to IconButton, and reorders parameters in IconToggleButton"
Change-Id: I0a9419b1a631cadad451395302ad87b7f9214f96
M ui/ui-material/api/current.txt
M ui/ui-material/api/public_plus_experimental_current.txt
M ui/ui-material/api/restricted_current.txt
M ui/ui-material/src/commonMain/kotlin/androidx/compose/material/IconButton.kt
cl...@google.com
an...@google.com
lp...@google.com
Yep, your implementation seems reasonable / how we would implement this. There are some questions around whether this behavior is easy to understand / expected, but at least for the migration case it seems reasonable to support in some capacity.
al...@gmail.com
I'll leave it up to your team to decide, but IMO (regardless of whether the behavior is easy to understand/expected), this behavior definitely has its benefits. One example where we depend on it in our own app is when placing surface-background-colored components on top of bottom-sheets. Without the concept of absolute elevation, those components end up looking like dark punch-out holes against a much brighter bottom sheet background in dark mode.
Just wanted to share my experience. :)
ch...@google.com
Thanks to Louis for pointing me towards AmbientElevationOverlay and ElevationProvider as a way to make this a bit easier to implement.
ap...@google.com
Branch: androidx-master-dev
commit a632fa2b38d798a4350214875b4e3695ebc0d0b6
Author: Louis Pullen-Freilich <lpf@google.com>
Date: Thu Oct 22 16:44:07 2020
Adds AmbientAbsoluteElevation to represent the sum of elevation provided by Surfaces. Also changes Surface to use this absolute elevation when calculating elevation overlays, to represent the total elevation at that point in the hierarchy, and not the elevation of the nearest Surface.
Bug:
Test: ElevationOverlayTest, SurfaceTest
Relnote: "Surface now uses the absolute (total) elevation when calculating elevation overlays, so a Surface nested in another Surface will use the combined elevation to draw the overlay."
Change-Id: I7bd2b08da276d5624baad6a2e59eb74bc021bc45
M compose/material/material/api/current.txt
M compose/material/material/api/public_plus_experimental_current.txt
M compose/material/material/api/restricted_current.txt
A compose/material/material/samples/src/main/java/androidx/compose/material/samples/ElevationSamples.kt
M compose/material/material/src/androidAndroidTest/kotlin/androidx/compose/material/ElevationOverlayTest.kt
M compose/material/material/src/androidAndroidTest/kotlin/androidx/compose/material/SurfaceTest.kt
M compose/material/material/src/commonMain/kotlin/androidx/compose/material/Elevation.kt
M compose/material/material/src/commonMain/kotlin/androidx/compose/material/Surface.kt
lp...@google.com
al...@gmail.com
Woot thanks Louis!
Description
Inhttps://github.com/material-components/material-components-android/blob/89a1bf883fa614702bb43d2cfa75a38005a42421/lib/java/com/google/android/material/internal/ViewUtils.java#L259-L271
material-components-android, views automatically inherit the elevation of their parentViewGroups using this utility method:For example, say you have a
MaterialButton(with 4dp elevation) contained inside of aBottomSheet(with 16dp elevation). In dark theme, theMaterialButtonwill inherit theBottomSheet's elevation, meaning that its elevation overlay will render as if theMaterialButtonhad 20dp elevation instead of 4dp elevation.It would be useful if there was a builtin mechanism to support this in Compose. This would make it easier to migrate UIs written with material-components-android to Compose while still maintaining UI consistency.