Hey everyone! As a software engineer at Google and...

# compose

[Uchenna Okoye]

Hey everyone! As a software engineer at Google and the POC for Foundation Layouts in Jetpack Compose, I'm in the process of exploring new feature ideas for Foundation Layouts, including Row, Column, FlowRow, WindowInsets, Box, Spacer, Offset, Padding, Aspect Ratio, among others. I'd love to hear your thoughts and suggestions on what features you believe are crucial or beneficial for the layout domain. What improvements or new functionalities would you like to see?

[Pablichjenkov]

An off the shelf SuperpositionLayout or OverPositionLayout, not sure what term to use for these.

[Uchenna Okoye]

Do you mean something like z-index positioning for overlapping elements? Have you had a chance to explore using ConstraintLayout in Compose for this purpose? It offers a lot of flexibility for layering. Here's a quick link for reference: ConstraintLayout in Compose.

[Pablichjenkov]

But isn't the constraint-layout bad in compose? That's what I have been hearing

[andrew]

Is there a more ergonomic way to go between WindowInsets and PaddingValues? Especially when it involves modifying the values returned? I’d definitely like a way to just add multiple padding values together. Right now this extension function isn’t ideal

[Uchenna Okoye]

@Pablichjenkov Thanks for your input. I'll note this down and see if we can offer alternatives to ConstraintLayout that might better meet positional needs .If you ever give ConstraintLayout in Compose a try, your feedback would be invaluable to us!

[Uchenna Okoye]

@andrew Thanks for highlighting the issue with transitioning between WindowInsets and PaddingValues. We're taking notes on these concerns and exploring enhancements.

[Pablichjenkov]

Ah ok Uchenna, yes I use it, I mean in production Apps. It is good, no major complaints so far, is just that I keep hearing is bad for performance.

[Sergey Y.]

Hi 🙂.
Inspired by Flutter's intuitive AnimatedContainer, I propose an "Implicit Property Animations" for Jetpack Compose layouts.
This feature would automatically animate changes in size, color, and position offsets, bringing simplicity to adding life to apps. Unlike AnimatedContent, which animates block transitions, this aims to ease animations for individual elements. It's crucial that this feature be toggleable and turned off by default, allowing developers to opt-in as needed.

[Sergey Y.]

fun ImplicitlyAnimatedBox() {
    var isExpanded by remember { mutableStateOf(false) }

    // Properties that would automatically animate when changed, if implicit animations are enabled
    val size = if (isExpanded) 100.dp else 50.dp
    val color = if (isExpanded) Color.Red else Color.Blue
    val offset = if (isExpanded) IntOffset(20, 0) else IntOffset(0, 0)

    Box(
        modifier = Modifier
            .size { size }
            .background { color }
            .offset { offset }
            .clickable { isExpanded = !isExpanded }
    )

So, no explicit animateColorAsState, animateDpAsState, etc used.
This feature would work implicitly, akin to how data diffing and smart recomposition operate for composable functions, automatically detecting and animating changes without explicit developer intervention.

[efemoney]

😅 https://issuetracker.google.com/issues/266550551

[Stylianos Gakis]

One thing I really would like to see revisited is how Column/Row composables treat their children with regards to what size they get in the cross-axis of the container composable.
I (and my colleagues) have been bit more times than I can count as to one behavior that I would be super happy to see work differently in the foundation APIs.
This conversation happened ~a year ago over here too which kinda covers my complaint too.
I had also filed this https://issuetracker.google.com/issues/274389472 issue.

Basically the fact the in a Column, if the column itself is 180.dp wide, the children that are entered in the column are not also 180.dp by default is super inconvenient.
Very often we need to either opt to make the children themselves also have the same hardcoded value, which is not optimal at all, and other times we simply opt for fillMaxSize() which is not what we really want either, since that could mean that it will tell the Column to expand further on its width without us wanting it to.
If the default width was 180.dp for the children too, the existing behavior would be very easily achievable with a wrapContentWidth(Alignment.Start), and you have the same behavior super easily if you for some reason want it. But for all other cases I do not remember one time that I was glad that the column behaved in that way.
This behavior becomes even more problematic when you got higher level composables like the material Card contain its content in an internal Column which you do not have access to, and then you are in this ColumnScope where you got this behavior imposed on your without much of a way to fix it without making a custom composable, which is exactly what we had to do to overcome this problem.

I would be very happy to see steps towards changing this behavior.

[Uchenna Okoye]

Thanks for bringing this up, @Stylianos Gakis. Sounds like something @Zach Klippenstein (he/him) [MOD] brought to my attention. We'll definitely add this as a queue of items to deliberate on. Thanks!