Description
Describe the project you are working on
A plugin with several custom control nodes, including containers. (Specifically, a container where children can be arranged in cells in a grid)
Describe the problem or limitation you are having in your project
The best way to detect new children it with the "child_entered_tree" signal. This works well in general, but it has a few issues:
- removing/re-adding the parent to the scene tree re-triggers it, causing additional overhead
- The parent (and child) must be active in the scene tree to register that a new child is added. In my case, if I create one of my containers in code, I can't directly position new children until the container is active in the scene tree. (In my project, children positions are tracked by the parent, and not dependent on arrival order)
Describe the feature / enhancement and how it helps to overcome the problem or limitation
I propose exposing Node's add_child() and remove_child() method as virtual methods (such as _ready(), etc.) so they can be overridden by custom controls. This would allow custom nodes to directly detect when a child is added or removed. (And would let them process children as soon as they are added, and not wait until entering the tree)
In a similar vein, #57541 addresses proposals #2544 and #724 to add signals to this effect by adding the "child_entered_tree" and "child_exited_tree" signals. As discussed above, there are still some scenarios where these signals are not the most desirable choice.
Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams
The methods would be exposed as virtual methods so they can be overridden in GDScript.
Since this is intended for derivative types, the default behavior can be accessed via the super.add_child()
If this enhancement will not be used often, can it be worked around with a few lines of script?
It can be worked around with the "child_entered_tree" signal, but as mentioned above, that has a few shortcomings. For my particular case, I could add specific methods to save transforms of the children until they enter the scene tree, but that's inconvenient and confusing if anyone else wants to use my plugin.
Is there a reason why this should be core and not an add-on in the asset library?
By definition, this would be a core change.