-
-
Notifications
You must be signed in to change notification settings - Fork 18.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Containers do not sort immediately when child top level changes #91227
Comments
Related: godotengine/godot-proposals#3081. |
ArchieVillain
added a commit
to ArchieVillain/godot
that referenced
this issue
May 1, 2024
When setting a control as top-level, containers would not sort their children, leaving a gap where the control was until a sort was queued afterwards. This has been fixed by adding a NOTIFICATION_TOP_LEVEL_CHANGED in canvas items that emits a top_level_changed signal which is tracked by containers. This signal and notification have also been added to Node3D nodes for consistency. Additionally, the editor continued to treat top-level controls within containers as being managed by them, preventing changes to their anchors and offsets. The reason for this was that the editor simply checked for a parent of type Container, entirely disregarding the control's top_level property. This has been fixed by replacing these checks with a is_managed_by_containers() method that also takes into account the top_level property of the control. The editor also now correctly informs the user that top-level controls can be freely positioned using anchors and the rectangle. Fixes godotengine#91227. Closes godotengine/godot-proposals#3081.
ArchieVillain
added a commit
to ArchieVillain/godot
that referenced
this issue
May 3, 2024
When setting a control as top-level, containers would not sort their children, leaving a gap where the control was until a sort was queued afterwards. This has been fixed by adding a NOTIFICATION_TOP_LEVEL_CHANGED in canvas items that emits a top_level_changed signal which is tracked by containers. This signal and notification have also been added to Node3D nodes for consistency. Additionally, the editor continued to treat top-level controls within containers as being managed by them, preventing changes to their anchors and offsets. The reason for this was that the editor simply checked for a parent of type Container, entirely disregarding the control's top_level property. This has been fixed by replacing these checks with a is_managed_by_containers() method that also takes into account the top_level property of the control. The editor also now correctly informs the user that top-level controls can be freely positioned using anchors and the rectangle. Fixes godotengine#91227. Closes godotengine/godot-proposals#3081.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Tested versions
Godot v4.3.dev (6118592), 4.2 and previous
System information
Windows 10.0.22631 - Vulkan (Forward+) - dedicated NVIDIA GeForce RTX 2070 (NVIDIA; 31.0.15.5186) - Intel(R) Core(TM) i7-10750H CPU @ 2.60GHz (12 Threads)
Issue description
Containers don't resort when a child's
top_level
is changed, even though this affects the Container's logic. The Container won't update until the scene is reloaded or it gets a sort children notification.Here is an example in BoxContainer, I use the visible property to force the Container to update.
Also, the Control Editor Plugin also still thinks that it is being controlled by its Container parent even though it is not.
To fix this, I think that changing
top_level
should send a sort children notification. The editor should also allow regular Control editing as if it wasn't in a Container.Steps to reproduce
top_level
in the child.Minimal reproduction project (MRP)
top-level-sort.zip
The text was updated successfully, but these errors were encountered: