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?

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

you can also use

ChrisBanes Insets library

if you want it explicitly, it has some functions regarding padding

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?

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.

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.

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.

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?

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

Sounds great! Thank you very much! 😄