Aloha! Last I checked, the M3 foundation & com...

# compose-wear

[Zoltan Demant]

Aloha! Last I checked, the M3 foundation & components were totally separate between the "regular" and wear variants. Meaning that ColorScheme, LocalContentColor, etc, were pretty much duplicated. Is this still the case today, and if it is - any plans to change that in the near future? I havent worked in the wear space for some time, but if I recall correctly there were too many differences between them to just have the same set of values?

[yschimke]

Good question. @stevebower can answer officially.

[yschimke]

If they could be shared it could make some higher level design system features possible across.

https://cs.android.com/androidx/platform/frameworks/support/+/androidx-main:compose/[…]/compose/material3/tokens/PaletteTokens.kt

https://cs.android.com/androidx/platform/frameworks/support/+/androidx-main:wear/com[…]/java/androidx/wear/compose/material3/tokens/PaletteTokens.kt

[yschimke]

But they appear distinct for now, looking at TypographyTokens, they don't match exactly.

[Zoltan Demant]

Agreed! And yep, looks like theyre distinct for now. Still curious if theres been any talks about merging them, maybe CMP, for wear? 🙂

[stevebower]

Hi - the color scheme and typography will continue to be different between Android and Wear in Material 3, because more colors/typescales are supported on mobile. However, we are working together to achieve consistency on naming, and in some cases there will be common types. For example, I believe the TonalPalette type should be shared, and then Android/Wear color scheme can be built from it (bearing in mind that for Wear, only a subset of the palette would be used).

[Zoltan Demant]

Excelent, thanks for the info! That sounds like a good middleground to me and Im all for it! Ive already built a sort of adapter/bridge between regular and wear M2 in the past, and I was mostly struggling with the fact that so many thing were the same, but duplicated; i.e. the story of LocalContentColor, meaning that I needed to create my own set of contentColorFor(x).. etc. Would be super-sweet if those were in some shared source 🙂 👍🏽

[stevebower]

Worth bearing in mind that Compose/Material and Wear/Compose/Material are treated as mutually exclusive, whereas Compose/Foundation and Wear/Compose/Foundation are treated as additive. That means that it shouldn't be necessary to need both forms of LocalContentColor, because only one would be present. If you find you want to mix the 2 material libraries (or the 2 material3 libraries), that suggests there's a gap in the components supported by Wear Compose component - so please let us know.

[Zoltan Demant]

From what I recall (its been a few years):
There was a Palette class, kind of similar to ColorScheme, just with a bunch of additional color pairs (background + foreground). In the same spot there was a foregroundFor(background); really similar to what material design does, just including those additional color pairs and using a different name so that I wouldnt mix them up. This was housed in a core/foundation module of the design system, without any components; and is what I wanted to re-use across regular & wear variants. Problem being that LocalContentColor was duplicated between the variants, so I needed to pass it into the palette somehow. Therefore, supersweet if there was something akin to M3:core where such things were housed, and could be shared too!