https://kotlinlang.org logo
j

John O'Reilly

12/17/2020, 5:24 PM
In SwiftUI if you do something like following (no params to
padding()
then default system padding values are used (using
Modifier.padding()
). In Compose it looks like
0dp
is used if no parameters are passed. Would be nice I think to use SwiftUI's approach here..
Copy code
VStack {
    ....
}
.padding()
b

Bryan Herbst

12/17/2020, 5:30 PM
What would the default padding be? 4dp? 8dp? I don’t think there’s a particularly valuable default value for a broad enough range of applications. I think the “default” padding will change between different apps with different design systems. That being said, if your application has a consistent default padding, I could see a lot of value in making your own Modifier like so:
Copy code
fun Modifier.defaultPadding() = Modifier.padding(8.dp)
3
j

Joost Klitsie

12/17/2020, 5:31 PM
Well why would there be a default padding? Wouldn't that have to rely on the design style you are using?
j

John O'Reilly

12/17/2020, 5:32 PM
Doesn't of course over all cases but material design I think generally recommends 16dp in many cases....might be a reasonable default anyway
j

Joost Klitsie

12/17/2020, 5:32 PM
yes in material design it makes sense
j

John O'Reilly

12/17/2020, 5:33 PM
I'm not sure how smart SwiftUI is when you don't pass in value regarding what value to use (based on for example form factor etc being used)
j

Joost Klitsie

12/17/2020, 5:33 PM
but compose !=material design
apple is very biased and they want you use their (outdated) design system, so of course they will incorporate it into the language
but compose is in essence a UI framework, opened up to support different design philosophies. They will however help you and deliver a material design library on top of it
but padding is part of the base stuff
so 0 padding is a sane default (I would argue that the argument should be specified at all times)
1
j

John O'Reilly

12/17/2020, 5:42 PM
what you'd almost need is some way to have certain defaults if say
MaterialTheme
was being used
which I imagine will be the case at least for most Android apps developed using Compose
j

Joost Klitsie

12/17/2020, 5:43 PM
But which default? material design often has 16dp space, but often there are different values. I guess having your own defaults would be an easy way to start
k

Kirill Grouchnikov

12/17/2020, 6:23 PM
I wouldn't want the underlying layer (which should be agnostic to the specific "philosophy" of a particular design system such as Material) to be in the business of providing default metrics of its own
👍 6
j

John O'Reilly

12/17/2020, 6:27 PM
Yeah, I can see now that this isn't quite as clear cut as I had thought initially 🙂
so, is it that
ButtonDefaults
is only applied when using
MaterialTheme
derived theme?
b

Bryan Herbst

12/17/2020, 6:33 PM
Correct-
ButtonDefaults
is part of
MaterialTheme
. In fact, all of
Button
is! There is no design system-agnostic button implementation in Compose.
k

Kirill Grouchnikov

12/17/2020, 7:32 PM
And I have my own for Aurora which is a separate desktop-only design "system" - https://github.com/kirill-grouchnikov/aurora/blob/master/component/src/desktopMain/kotlin/org/pushingpixels/aurora/component/AuroraButton.kt#L75 for buttons as an example
So I definitely wouldn't want any non-zero paddings to be forced by the underlying layers
j

John O'Reilly

12/17/2020, 7:38 PM
Yeah, makes sense.....if this was to be possible then I guess it would have to be done under the "umbrella" of
MaterialTheme
as is being done for Button as mentioned above
k

Kirill Grouchnikov

12/17/2020, 7:41 PM
Right, because of the specific 4/8dp underlying grid, touch size, minimum sizes, content paddings etc - for the specific system. I find this separation between the foundation layer and the material layer quite helpful.
4 Views