Composition of container behaviour in Container

[SLimeyMC]

Describe the project you are working on

A 3D game with a heavy artistic expression on the gooey, from the pain I had with this I decided to try making an addon including a blog about my journey however I am thinking of making it to the official engine (or rather the forked one lmao)

Having to align an element, then center it, and then putting an aspect ratio can be very cumbersome and result in deeply nested node hierarchies, leading to a less maintainable structure. This complexity arises from the fact that Container nodes only do one job and cannot be extended, only inherited in the scene tree. These responsibilities should be delegated through a flexible, modular system

Describe the problem or limitation you are having in your project

• Deep nesting: The need to combine multiple container behaviours results in nesting the scene tree by using Containers that only do one job differently, which can be both difficult to manage and harder to optimize

• Rigid Scene Structure: Once you have a scene you can't add more behaviour anymore since that require changing the original scene, with this proposal. To add a new behaviour is simply by parenting this to the editable children of the scene

Describe the feature / enhancement and how it helps to overcome the problem or limitation

The proposed enhancement is to introduce a composable behaviour system for Container nodes. This system would allow developers to dynamically apply behaviours to any Container through a set of modular components, rather than nesting multiple nodes or hardcoding logic.

This can be done through "node composition," where behaviour is delegated to child nodes responsible for applying specific layout rules. This decouples layout logic from the main Container node and allows for more complex layouts to be easily composed and adjusted.

For example, figure 2 could be done with this

Container
├ Panel1
├ Panel2
├ Panel3
├ MarginConstraint
└ ListLayout

This introduces

• Composable Layout Components (which follow Godot rule of thumb)
• Application on instantiated scene
• Reduced Node Hierarchies

Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams

In this proposal the Container is divided into 2 behaviours

• A Constraint describes the rectangle constraint where the layout must start and end, e.g. MarginConstraint, CenterConstraint, and BasisConstraint. Can have multiple Constraints where the rectangular can just be fed from the start and end with the last Constraint
• A Layout describes how each child must be placed within the rectangle, e.g ListLayout, GridLayout, and FlowLayout. Can only be one per Container as one would overpower others

If this enhancement will not be used often, can it be worked around with a few lines of script?

Can be worked around with class registry and EditorPlugin not convenient enough to use though.

Is there a reason why this should be core and not an add-on in the asset library?

A better-integrated tool to manage the Container, more chance for low-level optimization. It also introduces consistency with widespread adoption and a broader use case

[tokengamedev]

I believe padding (instead of margin) should be the property of the base container (may be all controls), that means every container has to have the property. This means every container should calculate the margin while calculating the size of the children. This also means MarginContainer will go away. I am not sure about the rest need to think over it.