Replace Margin and Anchor system with new system

[haaldor]

For now, Anchors and Margins are just variables that you should never touch, because they are changed by parent control nodes;
They are also are obsolete, as they are just a copy to the Rect Position & Size system;

On the other hand, right now we miss a system of variables that could edit how Control Node behaves in parent Control Nodes.

It doesn't make any sens to me, that every node has Margin variable, but to actually add margin to a node I have to add MarginContainer node between every single control node and it's child.
For example, to add ScrollContainer, right now you have to add ScrollContainer, than add MarginContainer to it, and than add VBoxContainer to MarginContainer, and like this every single time.

Not even mentioning how tedious it is now to animate movement of nodes, i.e. adding button sliding in from the left, but still having it as a part of VBoxContainer.

In my opinion we really lack something like CSS padding, margin & anchor system.

[theraot]

For now, Anchors and Margins are just variables that you should never touch, because they are changed by parent control nodes;

No, they don't. Anchors and Margins are relative to the parent. And if you mean containers, they bypass that entirely and go for Rect Position and Size.

They are also are obsolete, as they are just a copy to the Rect Position & Size system;

No, it is not a copy. Anchors and Margins tell the Control how to change Rect Position and Size when the parent Control resizes (and it is not a Container).

On the other hand, right now we miss a system of variables that could edit how Control Node behaves in parent Control Nodes.

If the parent is a Container, you are looking for Size Flags. Otherwise Anchors and Margins is what you want.

It doesn't make any sens to me, that every node has Margin variable, but to actually add margin to a node I have to add MarginContainer node between every single control node and it's child.

You don't have to, no. You can edit Anchors and Margins. Although, a MarginContainer might be easier to use since the usage of Anchors and Margins isn't communicated well. However…

For example, to add ScrollContainer, right now you have to add ScrollContainer, than add MarginContainer to it, and than add VBoxContainer to MarginContainer, and like this every single time.

Right. Once you are placing the controls inside a container (ScrollContainer in this case) then Anchors and Margins are out of the window. So MarginContainer is the only option.

Not even mentioning how tedious it is now to animate movement of nodes, i.e. adding button sliding in from the left, but still having it as a part of VBoxContainer.

You can animate Rect Position directly. And when I say animate, I mean with a Tween or an AnimationPlayer. And you don't even have to make an animation for every button, instead you can change the Root Node of an AnimationPlayer to have the animation apply to a different Node.

And be gland you can because in Godot 4 - thanks to #2841 - they are hidden when the Control is in a Container, so you can't make a track in the AnimatorPlayer.

In my opinion we really lack something like CSS padding, margin & anchor system.

I would prefer something closer to WInForms. But, yes, there is room for improvement.

[haaldor]

No, it is not a copy. Anchors and Margins tell the Control how to change Rect Position and Size when the parent Control resizes (and it is not a Container).

That's the issue though, why have a system in place that is not useful in 99% of cases (as pretty much always parent node will be either a container or not a control node at all).
In my opinion it's absolutely counter-intuitive, that Margins and Anchors do different thing, depending on what parent node is.
If parent node is a container, it absolutely can influence rect position and size directly, taking min rect size into calculations. In that case, margins and anchors could be used for what they are meant to, and taken into calculations as well.. instead of being overwritten by calculations.

You can animate Rect Position directly.

Yes, you can... until an update is forced for that node, which resets the position and size to calculated by parent container. In other words, you can by utilising an issue in update cycle/glitch, instead of having explicit option to do so.

I would prefer something closer to WInForms.

I haven't done anything in WinForms before, but from what I've searched it looks like it's the same system as CSS's... I might be mistaken though. Either way, both concepts implement what Godot lack.

I'm not saying Margin & Anchors system is completely wrong - it's just not useful, when parent node is Container; And as every control node that has child Control nodes should be a container, we can shorten it to "it's just not useful".

[theraot]

That's the issue though, why have a system in place that is not useful in 99% of cases (as pretty much always parent node will be either a container or not a control node at all).

You can add Control children to other Controls which are not Containers. Try it. I suggest the base class Control, or Panels for that.

In my opinion it's absolutely counter-intuitive, that Margins and Anchors do different thing, depending on what parent node is.
If parent node is a container, it absolutely can influence rect position and size directly, taking min rect size into calculations.

Agreed.

In that case, margins and anchors could be used for what they are meant to, and taken into calculations as well.. instead of being overwritten by calculations.

Yes, in theory they could. But sadly not in practice. Containers are meant to allow custom layouts, and trying to honor Anchors and Margins would get in the way. Ultimately it is a fight between we positioning the Control and the Container positioning the Control.

However, this conversation gave me an idea that I'll post on a separate reply.

Yes, you can... until an update is forced for that node, which resets the position and size to calculated by parent container. In other words, you can by utilising an issue in update cycle/glitch, instead of having explicit option to do so.

This is how you solve this: You add a Control (which is not a Container) to the Container, so the Container will position that one. And as a child of that Control (which - again - is not a Container), you add what you actually want, which ten you can animate with no issue.

And as every control node that has child Control nodes should be a container, we can shorten it to "it's just not useful".

Containers can have non-container children. In fact, I bet you have been doing it all this time. And non-container Controls can have children Controls too. I reiterate: try it.

[theraot]

It appears that things would be better if we didn't need MarginContainer, PanelContainer and ScrollContainer. And there is a way to do it: to the Anchors and Margins computation add position offsets given by the parent node.

• ScrollContainer would not be a Container. just a Control that moves that position offsets, plus clipping and a scrollbar.

• PanelContainer would not be a Container. Just a Panel that adds an offsets based on the stylebox, plus clipping.

• MarginContainer would not be a Container. Just a Control that lets you specify the position offsets it gives its children.

The way I'm thinking it, there is a top, bottom, left and right offset. And how much of each is used is controlled by the Anchor of the children Node.

The drawback is, of course, that we would be making the computation more complex for every Control, not just those that use it. Yet, it might be worth it.