Status Update
Comments
so...@google.com <so...@google.com> #2
Branch: androidx-master-dev
commit ece1e0ac47be4572d97afef494a24827c014af57
Author: Nader Jawad <njawad@google.com>
Date: Mon Aug 24 20:47:20 2020
Fixed wrong constructor parameter order for Rect
Relnote: "Fixed issue where Rect function constructor
with Offset and radius would create the Rect in the
order of left, right, top, bottom instead of
left, top, right, bottom.
Removed deprecated companion methods on Rect in
favor of function constructors.
Added tests to verify methods in Rect.kt"
Change-Id: I0846006bd0ec7f1a0effd90490c93002b42e132b
Fixes: 165822356
Test: Added tests to RectTest
M compose/ui/ui-geometry/api/current.txt
M compose/ui/ui-geometry/api/public_plus_experimental_current.txt
M compose/ui/ui-geometry/api/restricted_current.txt
M compose/ui/ui-geometry/src/commonMain/kotlin/androidx/compose/ui/geometry/Rect.kt
M compose/ui/ui-geometry/src/test/kotlin/androidx/compose/ui/geometry/RectTest.kt
lp...@google.com <lp...@google.com> #3
You meant only when the incoming min constraints are zero?
Ah yes, sorry :)
Updated my original comment accordingly.
po...@google.com <po...@google.com> #4
This is worrying me a bit, given that we have been moving away from infinite measurements. At the same time, I believe having such modifiers would not bring the same set of problems.
My concern would be to see people writing MyMaterialComponent(LayoutHeight.Min(0.5dp)) to achieve wrap content and bypass the material defaults.
Just to make sure we are on the same page, this problem manifests only when you want the component to have a smaller min size than its default, or a larger max size than its default, right?
lp...@google.com <lp...@google.com> #5
My concern would be to see people writing MyMaterialComponent(LayoutHeight.Min(0.5dp)) to achieve wrap content and bypass the material defaults.
I actually have no concern here, is this any different from writing: MyMaterialComponent(LayoutHeight.Min(5dp))
? Or what about MyMaterialComponent(LayoutHeight.Min(1dp))
? I don't think we can draw a line where a certain number is reasonable, and another is a 'hack' to remove default constraints. In every case I see an explicit developer intention - if a developer asks a component to have a min height of 0.5dp, we should respect that.
Just to make sure we are on the same page, this problem manifests only when you want the component to have a smaller min size than its default, or a larger max size than its default, right?
Yes, for other cases setting Min
or Max
directly will work, if developers are not changing the lower bound / higher bound respectively.
lp...@google.com <lp...@google.com> #6
Conceptually, this is extending on top of the way we treat infinity differently from a very large integer to also treating 0 differently from a very small integer.
Agreed, I think it's slightly awkward to treat 0 as special. Perhaps null
is more meaningful here, instead of using 0 and infinity?
po...@google.com <po...@google.com> #7
I actually have no concern here, is this any different from writing: MyMaterialComponent(LayoutHeight.Min(5dp))? Or what about MyMaterialComponent(LayoutHeight.Min(1dp))? I don't think we can draw a line where a certain number is reasonable, and another is a 'hack' to remove default constraints. In every case I see an explicit developer intention - if a developer asks a component to have a min height of 0.5dp, we should respect that.
My concern is not necessarily where the line is, but that there is a line where the behavior of the layout is non-monotonic. I agree it's still explicit developer intention which is why I think we should consider the idea. The question is if we prefer to integrate the explicit intention in the layout system or do it the old way with parameters on the component :)
Agreed, I think it's slightly awkward to treat 0 as special. Perhaps null is more meaningful here, instead of using 0 and infinity?
Yeah, we could have an unspecified constraint value (perhaps NaN if we use float in layouts) and force constraints to be non-zero and finite.
lp...@google.com <lp...@google.com> #8
Clarified offline, size is customizable if we set a fixed height, as incoming fixed constraints cannot be changed further down the line. However in the case of Fabs, where we set a min height, we would still need something like the proposal here to make that case work.
gv...@google.com <gv...@google.com> #9
Any updates on this?
FTM, I'm specifically interested in CircularProgressIndicator
po...@google.com <po...@google.com> #10
The modifiers requested in this bug should not be needed for CircularProgressIndicator. To set the size of CircularProgressIndicator you can just pass a preferredSize modifier to it. Let me know if you have a different use case and you would like us to prioritise this bug for dev09.
po...@google.com <po...@google.com> #11
Likely no time for this in dev10, punting to dev11.
po...@google.com <po...@google.com>
ap...@google.com <ap...@google.com> #12
Branch: androidx-master-dev
commit 9c66a60418a54c832df0e585b77b9426678206b8
Author: Mihai Popa <popam@google.com>
Date: Wed Apr 29 11:50:41 2020
Add defaultMinSizeConstraints layout modifier
The CL adds the defaultMinSizeConstraints layout modifier, which is able
to set additional size constraints to the wrapped layout, the additional
constraints only being applied if the incoming corresponding ones are
0.ipx for min[Width/Height] and IntPx.Infinity for max[Width/Height].
This modifier can be useful for example to set a default min size of a
component while still keeping the component wrap content, with the
default being overridable with smaller min values where the component is
used.
Relnote: "Added defaultMinSizeConstraints layout modifier, which sets size constraints to the wrapped layout only when the incoming corresponding constraints are unspecified (0 for min constraints and infinity for max constraints)."
Bug: 150460257
Test: LayoutSizeTest
Change-Id: I311eaf525d05eea9f657f583da7fdf845ad8d64f
M ui/ui-layout/api/0.1.0-dev11.txt
M ui/ui-layout/api/current.txt
M ui/ui-layout/api/public_plus_experimental_0.1.0-dev11.txt
M ui/ui-layout/api/public_plus_experimental_current.txt
M ui/ui-layout/api/restricted_0.1.0-dev11.txt
M ui/ui-layout/api/restricted_current.txt
M ui/ui-layout/samples/src/main/java/androidx/ui/layout/samples/SizeModifierSample.kt
M ui/ui-layout/src/androidTest/java/androidx/ui/layout/test/LayoutSizeTest.kt
M ui/ui-layout/src/main/java/androidx/ui/layout/LayoutSize.kt
M ui/ui-material/src/main/java/androidx/ui/material/FloatingActionButton.kt
ca...@gmail.com <ca...@gmail.com> #13
ca...@gmail.com <ca...@gmail.com> #14
I'm not able to create a CircularProgressIndicator
smaller than 48dp. Its implementation specifies .size(CircularIndicatorDiameter)
and seems to override whatever size I specify.
lp...@google.com <lp...@google.com> #15
Not sure what you mean, it should work fine if you do:
CircularProgressIndicator(Modifier.size(20.dp))
li...@gmail.com <li...@gmail.com> #16
@Composable
private fun LoadingView() {
Row(modifier = Modifier.height(IntrinsicSize.Min)) {
CircularProgressIndicator(Modifier.fillMaxHeight())
Text(text = "Loading")
}
}
Description
I've noticed more and more we have components with some sort of default size:
Icon - 24 x 24dp
CircularProgressIndicator - 48 x 48dp
FAB - 56 x 56dp
Unfortunately the size of these components is not customisable by SizeModifiers, so developers have no way to change the size without us explicitly providing a
width: Dp, height: Dp
|sizeModifier: SizeModifier
or similar, which is definitely a sad API given the re-usability goals of modifiers.The best we can currently do is setup these min sizes by using
LayoutSize.Min
inside the components, that way at least developers can increase the size, but they still have no way to decrease the size of a component.This actually even affects us, for example the base FAB has a min height of 56.dp, but the extended FAB that we also provide has a min height of 48.dp, so currently the only way we can configure this is by having a
minSize
param on the FAB itself.We discussed offline, but I believe a neat solution here could be a
Layout(Width|Height|Size).MinDefault
modifier, that will set minimum constraints only if the incoming constraints have a minimum of zero. That way developers can still explicitly make the component bigger or smaller, just by using normal modifiers, but if none are provided we can correctly size the component to its recommended default.