Godot-proposals: Adding Z Ordering for Control Nodes and/or for Dialogs

[Harutami]

Describe the project you are working on: I am working on a PC Simulator with WindowDialogs in it.

Describe the problem or limitation you are having in your project: For all Control nodes you can't set a z order. That's especially problematic with Dialogs. (I've tried it with putting a Node2D as a parent of a dialog and then trying to z order but that didn't work probably because it orders the z axis in the order of the Nodetree).

Describe the feature / enhancement and how it helps to overcome the problem or limitation: Adding z ordering into Control nodes or at least for the Dialogs like with Node2D (And maybe a CheckButton class if you want to disable the ordering with the Nodetree).

Describe how your proposal will work, with code, pseudocode, mockups, and/or diagrams: I don't know how it could be done because I am not familiar with the Engine, but I think that it could be built like the Node2D.

(I don't know if this is a good reference)
https://github.com/godotengine/godot/blob/master/scene/2d/node_2d.cpp

If this enhancement will not be used often, can it be worked around with a few lines of script?: I don't think so because it would be an enhancement to the core of control nodes and/or dialogs.

Is there a reason why this should be core and not an add-on in the asset library?: Because I think that adding z ordering for Control Nodes can be helpful in many ways (not only in dialogs) and many people seem to have problems with it.

Here is a discussion about it. I've tried it with those possible solutions but it didn't work either way.
https://github.com/godotengine/godot/issues/7692

[cgbeutler]

Your links are broken to the click, but work when copied and pasted. You may need to change their underlying target.

[Harutami]

Yeah, it's updated now. Thought I needed to extra link it.

[PrestonKnopp]

I don't think this is a good idea. Control nodes receive input depending on tree order. Tree order determines draw order. Z-index would make input counterintuitive.

Rather than using a z-index the following API should be used: Node.move_child() and Node.raise().

[Zireael07]

I had an equipment panel made of vbox and hbox containers that I had to scrap and do line by line because of draw order issues (a submenu child of a button would be drawn over by other buttons in the container).

This proposal would have allowed me to keep the original, much more intuitive scene design instead of having to have a control per row (and bottom-up by hardcoding margins)...

[MaaaxiKing]

I think this i a good idea and CanvasLayers are unnecessary then.

[ghost]

Great idea, it should help changing the workflow of arranging UI.

[Calinou]

@Gerarama Please don't bump issues without contributing significant new information. Use the :+1: reaction button on the first post instead.

[CarlGustavAlbertDwarfsteinYung]

Hi everyone.

Here is an actual case that requires the ability to change z order of menus.

In my project the game node game is dynamically generated and added only if the Player begins a new game from the main menu node. The hud node is associated with the game because it updates player attributes dynamically. However, Godot will automatically add the node below the menu making hud take precedence.

This means I would have to have my hud loaded before my game even begins. Hud is dependent on my player information so it will not work properly. There are indeed some solutions such as changing the menu position or adding the game before menu though it does seem very awkward that you cannot simply make the menu render on top of everything else. In most interfaces there is an option to keep some controls on top forcing them to render first.