Status Update
No update yet.
Comments
an...@google.com
object Button {
private val ButtonHorizontalPadding = 16.dp
private val ButtonVerticalPadding = 8.dp
/**
* The default inner padding used by [Button]
*/
val DefaultInnerPadding = InnerPadding(
start = ButtonHorizontalPadding,
top = ButtonVerticalPadding,
end = ButtonHorizontalPadding,
bottom = ButtonVerticalPadding
)
/**
* The default min width applied for the [Button].
* Note that you can override it by applying [Modifier.widthIn] directly on [Button].
*/
val DefaultMinWidth = 64.dp
/**
* The default min width applied for the [Button].
* Note that you can override it by applying [Modifier.heightIn] directly on [Button].
*/
val DefaultMinHeight = 36.dp
/**
* The default disabled background color used by Contained [Button]s
*/
@Composable
val defaultDisabledBackgroundColor
get(): Color = with(MaterialTheme.colors) {
// we have to composite it over surface here as if we provide a transparent background for
// Surface and non-zero elevation the artifacts from casting the shadow will be visible
// below the background.
onSurface.copy(alpha = 0.12f).compositeOver(surface)
}
/**
* The default disabled content color used by all types of [Button]s
*/
@Composable
val defaultDisabledContentColor
get(): Color = with(MaterialTheme.colors) {
EmphasisAmbient.current.disabled.applyEmphasis(onSurface)
}
}
I am not sure the composable getters should be placed in a file with such name.
in the same way this would be a mistake to rename this class to FooConstrants
object Scaffold {
/**
* The possible positions for a [FloatingActionButton] attached to a [Scaffold].
*/
enum class FabPosition {
/**
* Position FAB at the bottom of the screen in the center, above the [BottomAppBar] (if it
* exists)
*/
Center,
/**
* Position FAB at the bottom of the screen at the end, above the [BottomAppBar] (if it
* exists)
*/
End
}
}
and what about this use case, it was about namespacing, not defining constants:
object TabRow {
/**
* Data class that contains information about a tab's position on screen
*
* @property left the left edge's x position from the start of the [TabRow]
* @property right the right edge's x position from the start of the [TabRow]
* @property width the width of this tab
*/
@Immutable
data class TabPosition internal constructor(val left: Dp, val width: Dp) {
val right: Dp get() = left + width
}
/**
* Positions and animates the given [indicator] between tabs when [selectedIndex] changes.
*/
@Composable
fun IndicatorContainer(
tabPositions: List<TabPosition>,
selectedIndex: Int,
indicator: @Composable () -> Unit
) {
...
}
}
js...@google.com
Yeah, point taken, although that might be a matter of semantics. One alternative way of looking at it is that enums and various helper functions are technically all constants, as they aren't values that change over time. IIRC this is partly why FooConstants was chosen over FooDefaults.
I seem to recall that also being mentioned at API Council, and while the name might not be a perfect fit for all circumstances, it is still valuable to be consistent and the new name is better than overloading the same name as the widget which would lead to confusion. If you have an idea for an alternate naming pattern which we haven't considered, I'm sure we'd be happy to re-evaluate.
an...@google.com
js...@google.com
Would IndicatorContainer be used outside a TabRow? If not, perhaps it should be thrown on a receiver scope to make it easy to use from within the proper scope and hard to use from outside a TabRow? The API for IndicatorContainer as it stands today perhaps isn't super discoverable?
I don't have a strong opinion about where the functions live, and there are some judgement calls there, but I don't think that should block the renaming of these objects. Maybe +George or +Adam will have opinions here.
js...@google.com
Interestingly, just looked back at the API Council pod notes, and it makes explicit mention of these caveat:
Scaffold.FabPosition enum conflicts with the above decision about ScaffoldConstants
-> Move FabPosition enum to top-level
Revisit TabRow.Indicator/IndicatorContainer
-> Docs and samples please!
lp...@google.com
One alternative way of looking at it is that enums and various helper functions are technically all constants, as they aren't values that change over time. IIRC this is partly why FooConstants was chosen over FooDefaults.
This seems to be the opposite actually, no? The point is that these numbers are strictly tied to the spec, and so can / will change if the spec updates the internal padding for a Button for example. This allows developers to build their own components, point to these 'defaults', and always be matching the spec. For that reason, Defaults makes more sense to me, as there's no guarantee of stability.
js...@google.com
Constants "won't change over time" as in "are not mutable vars changed by the program during normal execution", as defined by wikipedia:
an...@google.com
ap...@google.com
Branch: androidx-master-dev
commit 7bb5f31e522b202ec7d7eeb1ec468d7795630a75
Author: Andrey Kulikov <andreykulikov@google.com>
Date: Fri Jun 26 12:53:36 2020
Rename Button object to ButtonConstants
Fixes: 159687878
Test: manually
Relnote: Rename Button object (containing the defaults used by Button function) to ButtonConstants
Change-Id: I7c5f7d864984502bc477c3d42896f052b25c1db3
M ui/ui-material/api/0.1.0-dev15.txt
M ui/ui-material/api/current.txt
M ui/ui-material/api/public_plus_experimental_0.1.0-dev15.txt
M ui/ui-material/api/public_plus_experimental_current.txt
M ui/ui-material/api/restricted_0.1.0-dev15.txt
M ui/ui-material/api/restricted_current.txt
M ui/ui-material/samples/src/main/java/androidx/ui/material/samples/ButtonSamples.kt
M ui/ui-material/src/main/java/androidx/ui/material/Button.kt
js...@google.com
What about FilledTextField, and OutlinedTextField?
js...@google.com
What about FilledTextField and OutlinedTextField?
Description
TLDR: The
object Buttonshould be renamedobject ButtonConstants. Similarly we should probably renameScaffold,TabRow,FilledTextField,OutlinedTextField(and are there any others?) to follow the same pattern.As per Compose API Council on April 6, 2020, we decided the public constants for any composable
Fooshould go on an object calledFooConstantsinstead of an object namedFoo. The primary motivation is that there is a naming overload/collision such that when you search for a widget by name in AndroidStudio, you would naturally open the wrong object and then get confused by how it worked, although there were also other similar considerations that pushed us in this direction.