https://kotlinlang.org
Join Slack
In SwiftUI if you do something like following (no params to `padding()` then default system padding ...
# compose
j
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
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
Well why would there be a default padding? Wouldn't that have to rely on the design style you are using?
j
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
yes in material design it makes sense
j
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
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
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
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
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
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
Correct- 
ButtonDefaults
is part of 
MaterialTheme
. In fact, all of 
Button
is! There is no design system-agnostic button implementation in Compose.
k
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
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
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
Open in Slack
PreviousNext
Powered by

kotlinlang

A modern programming language that makes developers happier.

Powered by