Is there a composition local for the surface backg...
# compose
u
Is there a composition local for the surface background color?
Copy code
private object MaterialRippleTheme : RippleTheme {

    @Composable
    override fun defaultColor() = RippleTheme.defaultRippleColor(
            contentColor = LocalContentColor.current,
            lightTheme = MaterialTheme.colors.isLight
        )
I see default ripples pick up content color via the
LocalContentColor
composition local. I'd like to have my system pickup background color. Is there a comp. local for that, or do I need to roll in my own?
a
the color of surfaces can by changed by modifying your material theme. See
MaterialTheme.colors.surface
. The
Surface
composable uses the surface color and doesn't have any sort of background color. AFAIK it is backed up by some sort of composition local (that's how material theme works under the hood) what are you trying to achieve?
u
I dont want to change my surface backgrounds Just the ripple over it, conditionally on surface color
a
no such thing. you'd need to make your own
👍 1
l
Just the ripple over it, conditionally on surface color (edited)
FWIW this is basically what content color is, surfaces provide content color based on background color, but the calculation lives at the surface level, rather than providing background color and then calculating this later. But it’s still ‘derived’ from background color
u
hmm no sure if I follow Button is a surface, and a white button with blue text will give a blue ripple
l
Right, but by default the content color inside button is calculated from the background color, using
contentColorFor
It’s also intended that text color / ripple color are the same, if you want it to be different then you would need to define a custom theme for the ripples
u
yes I want a custom theme for ripples, either white or black but my designers chose to calculate it based on the background luminosity and I was hoping to have a smart ripple theme globally in one place such that it would calculate the ripple color so I dont have to provide it manually for any clickable surface
l
I guess my point is that it should be a responsibility of the surface to calculate and provide ripple colour, or else you will end up with an indirection where you need to provide background colour and separately calculate ripple colour based on that
E.g, there might be differences for light and dark theme, but you lose this information if you only provide a background colour. A dark background in light theme is different from a dark background in dark theme
u
right, but that means I need a
MySurface
?
l
Well, you would need that anyway because the background colour isn't provided in any case :)
u
right but none of the buttons and everything that builds on
Surface
wont work
oh well.. maybe I can just use contentColor luminosity to guesstimate if it needs white or black
l
Yeah, you would need to provide this colour at each component. And yeah, in material (not material3) the content colour luminosity is used for this purpose, it's a pretty reasonable approximation
👍 1
You'll still need to provide this RippleConfiguration for each component in any case, since this sort of global ripple customisation is not supported from 1.7 onwards
u
so overriding
LocalRippleTheme
is deprecated?
l
I would say in general this use case falls a bit outside material supported customisation. Changing the ripple colour separately from text colour is very likely to run into cases where contrast ratios are bad, and you introduce accessibility issues
👍 1
Screenshot_20240525-115938.png
l
Not really, I mean you can use it to provide global configuration but defining a static colour at the top level will be very broken :) It's meant for per component overrides, like to disable a ripple on a particular button
It doesn't support derived theming or anything that would be helpful for global configuration
u
hmm you mean that I can't query
LocalContentColor
there?
l
Yeah, it's just a basic object you provide with a raw color
185 Views