Hello, Why was this issue closed? <https://issuetr...

# compose-android

[louiscad]

Hello,
Why was this issue closed? https://issuetracker.google.com/issues/294046936

Both of these are *zero height*(!) when in a Column with the verticalScroll modifier than can scroll (i.e. content longer than the parent):

Spacer(Modifier.weight(1f).heightIn(min = 16.dp))

Spacer(Modifier.weight(1f).requiredHeightIn(min = 16.dp))

I have found NO working workaround.

There's also an abandoned issue on YouTrack: https://youtrack.jetbrains.com/issue/CMP-4212

[Louis Pullen-Freilich [G]]

Weight doesn't really make sense in a scrolling container, what do you intend to happen here? You might be better off making a custom layout / layout modifier, and adding verticalScroll to that if you have a strong opinion on desired behavior

[louiscad]

It does make sense when the container can't scroll

[louiscad]

Basically anytime you want evenly spaced things that don't waste space when the app window is small (e.g. in landscape mode, split screen…)

[louiscad]

It makes no sense that minimum dimensions are not respected because one adds scrolling.
The current behavior is not correct, why would you think otherwise?

[louiscad]

Is it because it is hard to implement?

[Louis Pullen-Freilich [G]]

I don't know if there is a correct behavior. What would you expect here? The contract of weight says it will divide remaining space, in a scrollable container (which can have infinite size) 'remaining space' doesn't make sense as a concept.

[Louis Pullen-Freilich [G]]

I agree that having zero height is wrong, but so is having the minimum height, and so is having infinite height

[louiscad]

What I expect is that:
• When the minimum height of the content is smaller than the scrolling container, remaining space is allotted to all the elements with a weight, starting with the smallest elements, and ignoring the minimum height to be perfectly evenly sized only once all the elements with a weight are past it.
• When the minimum height of the content is bigger than (or equal to) the scrolling container, just respect the minimum dimensions as if there was no scrolling involved, and there's no extra space to give anyway.

[Csaba Szugyiczki]

I think we miss the good old days, when it was just an xml attribute away, to make weight working in ScrollViews using the fillViewport=true trick.

[louiscad]

I have fillMaxHeight() set before the verticalScroll() on the Column of course

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

I do think there’s a more reasonable default behavior for weight to fallback to when the constraint is unbounded, but at this point changing it could break existing code so it’s not gonna happen.

[louiscad]

Waiting for Compose 10.0 to break bad design decisions then

[Tolriq]

Well https://bsky.app/profile/intelligibabble.bsky.social/post/3lxl243r4e222 let's hope we see a v10 🙂

[louiscad]

BasicTextField2 happened and became the BasicTextField replacement. Couldn't the same be done for Column and Row, somehow?

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

And make some new decisions that will be regretted - circle of life of a library lol

[louiscad]

Did that happen with BasicTextField2?

[louiscad]

BTW, no offense, but I'm happy to learn that Google would never break my code, be it for right or wrong reasons 😄

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

They try very hard not to

[Csaba Szugyiczki]

we could call it… weight2 to solve backward compatibility (and confuse everyone) 😅

[louiscad]

Actually, there could be an overload taking optional min: Dp and max: Dp parameters for both ColumnScope and RowScope.

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

I think there’s a real opportunity for someone to publish a little library with more flexible row and column layouts 😜

[louiscad]

And a lint that would flag usages of weight() +`heightIn(…)` / widthIn(…) / requiredHeightIn(…) / requiredWidthIn(…)

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

I think the just weight modifier itself could be a lot more configurable

[louiscad]

If it's not inside Compose itself, a lot more people will keep falling into that trap, and it's likely that only users might notice it…

[louiscad]

Discoverability is a lot harder too

[louiscad]

That makes me think about how FlowRow was more flexible in Accompanist than in Compose Foundation, and the Accompanist version was still made a lot harder to keep in a project 💀

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

I think there’s more appetite for risk in an incubator library like that

[romainguy]

What Louis said is why Views had a special attribute (fillViewport) in scrolling views. I don't think using weight here would be the right solution

[romainguy]

(or at least not without extra configuration)

[Stylianos Gakis]

Just add two spacers. One with the weight and one with the fixed size.
It works exactly as you'd expect it to work that way.

[Colton Idle]

I definitely did this recently (weight with a scrollable container) and it worked (i was surprised because i thought it was going to be a a real pain) but it worked nicely. i may have also used intrinsics, but what stylianos said works