Hi all :wave: I'm trying to adjust the style of my...
# compose
o
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.
s
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
o
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)
k
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.
1
a
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.
👍 1
o
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.
a
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.
👍 2
as a result, no one library composable has to take on the scope of being all things to all people
i
The various approaches are covered in the Custom design systems in Compose guide: https://developer.android.com/jetpack/compose/themes/custom
3
💯 2
o
@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
i
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
👌 1