I get to bug Googlers on here now :smile: When a `Row`'s incoming width is unconstrained, is it WAI ...

# compose

[Zach Klippenstein (he/him) [MOD]]

I get to bug Googlers on here now 😄 When a `Row`'s incoming width is unconstrained, is it WAI that it measures its weighted children as 0-width? That makes sense since Modifier.weight is intended to distribute "available space", and if the width constraint is infinity, then it can't do that (∞ / anything = ∞, and nodes can't have infinite measured width). If so, i'll file a CL to update the documentation.

[Stylianos Gakis]

Afaik this has been the behavior since forever. And the reason why weight basically does nothing in scrollable lists which make the constraints infinite as you describe. Is there some documentation that describes the opposite, or is it that it's simply not mentioned anywhere?

Also, welcome to being a compose consumer rather than builder yet again 😂

[Zach Klippenstein (he/him) [MOD]]

It makes sense from the rules. It feels weird somehow though. Stuff like this make Row hard to use as an implementation for libraries, and makes me even more persuaded that custom layouts are often the best thing. I’m not sure what a more reasonable default would be though. I think a doc update is probably the best thing to do.

[Stylianos Gakis]

Yup, tbh this and https://kotlinlang.slack.com/archives/CJLTWPH7S/p1712328544046829?thread_ts=1712320576.946129&cid=CJLTWPH7S are the two things which I've always found hard to accept that they are the way they are on column/rows 😅

[Zach Klippenstein (he/him) [MOD]]

I’ve been thinking about making a little library with alternatives to basic stuff like this that are more powerful. Cross-axis constraint propagation, default weight, explicit unspecified weight, proportional measuring, etc. Might try some of these ideas internally and if they actually work, publish them

[Stylianos Gakis]

Do it and name them "Column2" and "Row2", you've done it before, I know you can do it again 😅
If that library has one person using it I can absolutely guarantee you that it would be me.

[Zach Klippenstein (he/him) [MOD]]

Was thinking HStack and VStack 😜

[Stylianos Gakis]

Nooooooooo please no 😂

[shikasd]

HColumn and VRow

[Zach Klippenstein (he/him) [MOD]]

import cursedlayouts.*

[Zach Klippenstein (he/him) [MOD]]

Joking aside, I want to see if there’s a better way to provide this than composables. Eg maybe just extensible MeasurePolicy classes or helper functions.

Eg if we had something like this:

interface ScopedMeasurePolicy<ContentScopeT> : MeasurePolicy {
  val contentScope: ContentScopeT
}

@Composable
inline fun <ContentScopeT> Layout(
  measurePolicy: ScopedMeasurePolicy<ContentScopeT>,
  modifier: Modifier,
  content: @Composable ContentScopeT.() -> Unit
)

Then we could provide stuff like:

open class StackMeasurePolicy(
  val orientation: Orientation,
  val defaultChildWeight: Float = Unspecified,
  …
): ScopedMeasurePolicy<StackScope> {
  override val contentScope get() = StackScope

object StackScope {
  fun Modifier.weight(…): Modifier
  fun Modifier.weightUnspecified(): Modifier
  …
}

But probably with more extension points, injectable logic for certain things, etc. Consumers can then just pass an instance to that layout composable:

@Composable
fun MySpecialRow(
  modifier: Modifier = Modifier,
  content: StackScope.() -> Unit
) {
  val measurePolicy = remember {
    StackMeasurePolicy(…)
  }
  Layout(measurePolicy, modifier, content)
}

[Zach Klippenstein (he/him) [MOD]]

Another use case:
https://kotlinlang.slack.com/archives/C01D6HTPATV/p1723398029791999

[Stylianos Gakis]

In 100% of the places we use a weight, we basically do:

Column {
 Stuff()
 Spacer(weight(1f))
 Spacer(height(8.dp))
 MoreStuff()
}

To fight this. Because the weight can always evaluate to 0.dp and then they touch and basically it never is what we actually want in the places we put the weight in

[Zach Klippenstein (he/him) [MOD]]

Thinking about this more, I think I’ve convinced myself that using max intrinsic size would be the most reasonable default.

If weight means “take a fraction of the available space”, and 0-♾️ constraints means “be your natural size”, then the natural “available” width is the sum of all the children’s max intrinsic widths, because the total width can’t be more than that. I’m mostly convinced this makes sense, but it’s definitely arguable.

More importantly however, that’s moot because it’s probably way too late to change this behavior for Row/Column.

[Zach Klippenstein (he/him) [MOD]]

I also realized this behavior is documented on Row/Column itself, but not on the weight modifier itself. Who would think to look at the weight modifier kdoc for information about weight behavior anyway? 😏 So I’ll still fix this.

[Zach Klippenstein (he/him) [MOD]]

@Uchenna Okoye are you still looking for Row/Column ideas?

[Zach Klippenstein (he/him) [MOD]]

doc updates:
https://r.android.com/3216795
https://r.android.com/3216815

[Zach Klippenstein (he/him) [MOD]]

@Composable
inline fun LinearLayout(content: @Composable () -> Unit)

🧌