Hi <@UJBKXD0HH>, Any reason why, ```@Composable f...

# compose

[Archie]

Hi @Adam Powell,

Any reason why,

@Composable
fun TopAppBar(
    title: @Composable () -> Unit,
    modifier: Modifier = Modifier,
    navigationIcon: @Composable (() -> Unit)? = null,
    actions: @Composable RowScope.() -> Unit = {},
    backgroundColor: Color = MaterialTheme.colors.primarySurface,
    contentColor: Color = contentColorFor(backgroundColor),
    elevation: Dp = AppBarDefaults.TopAppBarElevation
) {
...
}

Doesn't expose contentPadding? Is it possible to request exposing the content padding to adding addition padding for WindowInsets would be easier?

[annsofi]

I don’t think you’re getting a reply any time soon from Adam considering it’s 5 in the morning his time zone

[annsofi]

maybe this helps? https://kotlinlang.slack.com/archives/CJLTWPH7S/p1611950231483800?thread_ts=1611948978.480300&amp;cid=CJLTWPH7S

[Vivek Sharma]

you can also use ChrisBanes Insets library if you want it explicitly, it has some functions regarding padding

[Archie]

Hi @annsofi, Thank you for the reply. I am actually aware of that approach but I feel like thats more of a workaround rather than a complete solution. Exposing the contentPadding would solve the issue without doing much work unless there's a specific reason for it not being exposed. Don't you think so?

[annsofi]

I haven’t looked into it much, but what I’ve seen is that they people building compose encourage creating issues in their tracker with feature requests and use cases that show why the request is a good thing, so I’m guessing that’s a good start. Maybe share that here and see if people star it and also want it.

[Archie]

Yes I agree.. I wanted to ask it here first to know whether filing it for a feature request would be good. I was thinking there might be a specific reason why it wasn't exposed in the first place so then I won't have to file a feature request for it.

[Adam Powell]

The only modification I would make to the accompanist solution above by way of direct changes to compose-material would be to extract a TopAppBarLayout composable that doesn't include an inner Surface at all, and have TopAppBar call it. Adding parameters in the vein of contentPadding is not sustainable for most composables and it's better to offer the building blocks beneath where parameters like that would be used to remix however you wish instead.

[Archie]

Hi @Adam Powell, thank you very for the reply. If I understood it correctly, that will be a change in the compose-material library right? Is that an already planned change for the future?

[Adam Powell]

Yes, it would be the addition of a middle-tier composable function but not a change to existing APIs

[Adam Powell]

the approach in accompanist works just fine until then, it's more of an optimization than anything else

[Archie]

Sounds great! Thank you very much! 😄

[Archie]

Oh, then how about:

@Composable
fun TopAppBar(
    modifier: Modifier = Modifier,
    backgroundColor: Color = MaterialTheme.colors.primarySurface,
    contentColor: Color = contentColorFor(backgroundColor),
    elevation: Dp = AppBarDefaults.TopAppBarElevation,
    contentPadding: PaddingValues = AppBarDefaults.ContentPadding,
    content: @Composable RowScope.() -> Unit
) {
...
}

Will this get affected as well? since it exposes contentPadding?