Well, the thing is that if you have already set the margin and then just want to set the alignment, you would overwrite the margin with 0,0,0,0. That's probably not what you would expect. It would of course be a bit weird to set this in two goes, but that's still not a good enough reason. I will try to make sure that the null thing is hidden behind the API.

I think the change can be done with just a single extra code line.

yeah. these settings would feel more intuitive if they were on the Nodes themselves. I know that the Nodes don’t know what containers they’ll be put in, but maybe a no-op would be better than calling a static method on a Parent class, passing in a reference, etc

Lik

vbox = VBox()

label = Label()

Yeah, we actually introduced hgrow/vgrow directly on Node, but that's not what I meant.

vbox.children.add( label )

I have committed the fix for the constraint builders now.

label.alignment = CENTER

Before, if you did this:

hboxConstraints { hGrow = Priority.ALWAYS }

, you would also apply

HBox.setMargin(node, Insets(0.0, 0.0, 0.0, 0.0)

to that Node. Now it will no longer touch the margin unless you set it.

It will also preserve the existing values for margin if you only change

marginTop

for example. Until now we would have overridden all the other sides with 0.0.

I made this change to all the constraint builders.

Basically, they are initialized like this now:

@User uploaded a file: Constraints extract the existing margin instead of resetting to 0.0

I pass in the node it is applied to now, but the public API doesn't change.

i was thinking of something more like CSS where you can set a value and it gets ignored if it’s not relevant

so you could set

lbl = Label() lbl.text = “My Content" lbl.alignment = CENTER lbl.margin = Insets(10.0)

and margin would be considered if it were needed

Absolutely, we can add those as well 🙂 It would have to inspect the parent and apply the correct alignment function though. And it would be a noop as you say if it has no parent, or if the parent is not of a known type. Right?

that seems more intuitive to me. i know the way you have it is the way that Javafx does it — separate out constraints from container and child nodes — but it seems like a long list of properties would document better

something like “margin - sets a margin for the Node when placed in HBox, VBox, or StackPane"

Absolutely.

Let me try to write one of those and see how it would feel.

yeah. i’m suggesting that these things are just one more property among many. of course, the implementations will be different

So, what nodes have margins besides hbox, vbox and stackpane?

Going through the subclasses

looks like alignment for StackPane, margins for the three you named, grow for hbox and vobx

then there are properties for borderpane and anchorpane. grid pane is different too