I have a case where I want to "tag" a certain subtree as a "logical" grouping of content. For example, in Office you have the ribbon "group", the footer "group", the taskpane "group". One option is to use an ambient to wrap that group, but it feels too heavyweight. And the other option is to use a modifier, but it looks like a modifier only gets "applied" to the specific composable. If I have another composable down the tree and I want to check which logical group it belongs to, there doesn't seem to be a way (by design?) to walk the modifiers of my parent chain. Should I go with ambients?

Another way is to explicitly pass the group identifier to the children, maybe using a receiver on your child composables

Would that need to be done explicitly however many nested levels I have in my hierarchy of composables?

Depends on how your composables are structured, you might be able to take advantage of lambdas and lexical scope

an ambient for this kind of metadata could be fine; I suppose it depends on what the group is used for and what the defined behavior is if something isn't in a group

(1) why do you want to know which group the widget belongs to? There are some valid reasons, but at first glance it sounds suspicious. (2) why can't you just pass the group in as a parameter to the widget(s) that need it?

I think of the UI hierarchy as a tree. Every node has a color. A child node inherits the parent color, unless that child is explicitly overriding it. So an application hierarchy can be seen as "red" toolbar, "blue" footer, "green" sidebar, etc, but at any level you can tweak the color, like yellow group of buttons in a blue footer. And there's the default color set on the root.

Are we literally talking about color here? Or are you still trying to ask the question in the abstract?

Passing this indication around is cumbersome. In my particular case, application UI is partitioned into functional areas, each with its own theme. So a footer button looks different from a toolbar button. It's not a color. It's the functional area type, which then is used to query the area theme.

But usually you would use

FooterButton

to build the footer and

Toolbarbutton

to build the toolbar. Unless you would sometimes put buttons that are normally in the footer into the toolbar?

Why would the UI builder need to know where the button goes. If it's a button that boldens the text, that's what the button is. The look shouldn't be a part of the button creation, imo

one might similarly say that the button shouldn't concern itself with the group it's in

Exactly. It's only at the draw time that it queries the colors and draws itself. Because that needs to happen at some point. Otherwise how do you create visual separation?

A button concerning its self with how it looks is literally THE thing a button should be doing.

"group" is still kind of vague here in terms of its intent and the data involved

Toolbar is a group, but then a search field in it is a subgroup

so for theming, then?

it would be a stretch to call that theming

I see a world where the button adapts to the area when it draws itself, instead of doing that at creation time. This way you can have metadata that captures what the button is, and let the button figure out how to draw itself wherever it is in the application hierarchy.

That inverts the decision making in a way that is antithetical to Compose.

At least this is the design system that I'm porting to compose desktop from swing

Children should not know about their parents, because that prevents reuse in contexts that the Child wasn't originally expecting but that the parent knows about

That's the whole point of ambient "overriding" of colors, text styles, etc already today

Ambients are like nuclear weapons, you really shouldn't use them unless you absolutely must, and even then you should feel bad.

That's exactly my use case

it is not, those ribbons are small and relatively flat

Here's a few examples of desktop apps with clear logical separation of complex UI surfaces into functional areas. And on desktop, controls such as buttons have many more states (and combinations of thereof) than what is right now available for app customizations via https://android.googlesource.com/platform/frameworks/support/+/refs/heads/androidx-master-dev/compose/material/material/src/commonMain/kotlin/androidx/compose/material/Button.kt#295

I'm not saying that apps don't have clear logical separation of complex UI into functional areas.

There's enabled bit, selected bit, pressed bit, rollover bit - and highly customized UIs provide distinct visuals for different combinations of these bits.

We are diverging pretty substantially from your original ask. Are you trying to build a design system, or trying to build some panels using an existing design system?

It's the former