Hi all :wave: I'm trying to adjust the style of my...

# compose

[Olivier Patry]

Hi all 👋
I'm trying to adjust the style of my buttons. I'd like all my `Button`s to have the same style, same is for `OutlinedButton`s.
I was able to tweak some parts like shape & surface given the MaterialTheme open properties but if I want to customize more, I'm stuck.
For instance, I'd like to tweak the width of the `OutlinedButton`'s border and potentially its color.
The only thing I can think of so far is to redefine my own MyAppButton tweaking what's needed (by calling built-in button composable or not, impl detail here).
Can't we have ways to override ButtonDefaults? (using opened var instead of val or LocalButtonDefaults or something like that).

I have the feeling that redefining custom buttons make composable less reusable and tightly coupled to custom composable rather than provided theming.

[Simon Stahl]

Not sure if you can do the border width, but you can definitely change the font, colors and some other things with a custom theme. I started by copying MaterialTheme and adjusting as needed

[Olivier Patry]

Yes that's what I did, used that to customize shape and surface for instance. But it's limited to what is made available on MaterialTheme (ie. not border color and width)

[Kirill Grouchnikov]

This has been discussed before. The Button composable is a part of the specific design system implementation - Material design. If you start deviating from what that design system supports, you will need to create your own composables. Requesting that the UI toolkit supports all possible customizations (a couple for you, a couple more for somebody else, a couple here, a couple more there) is simply not a maintainable solution.

[Adam Powell]

additionally, the more properties of each UI element that can be changed through side channels like CompositionLocal theming elements, the more that the authors of other potentially reusable components like date pickers, etc. have to consider to make sure those components will work in all scenarios. In effect, the more of these implicitly inherited themeable parameters a composable supports, the less reusable it is since its behavior is less predictable in different situations.

[Olivier Patry]

Ok fair enough.

I understand we should consider material theme as an opinionated lib.

Either one should restart a whole theme and design system (using material as a basis or not) or just replace few components when needed.

I just wanted to be sure to not miss the point.

[Adam Powell]

no point missed. 🙂 The intention is that creating your own composables that fit your needs by either wrapping others with some custom properties or by redefining new behavior should be cheap to do and relatively frequent.

[Adam Powell]

as a result, no one library composable has to take on the scope of being all things to all people

[Ian Lake]

The various approaches are covered in the Custom design systems in Compose guide: https://developer.android.com/jetpack/compose/themes/custom

[Olivier Patry]

@Ian Lake awesome! That's exactly what I was looking for! 🙌

When digging on this topic I found the material theming guide bit missed the guide you shared here.

https://developer.android.com/jetpack/compose/themes/material

[Ian Lake]

Yeah, they're in the same section in the left hand nav, but they don't cross link to one another so I could easily see how it would be easy to miss