Add z_index property for Control nodes (like in Node2D)

[ghost]

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.
godotengine/godot#7692

[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.

[Calinou]

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

[ghost]

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.

[michaelpbl]

One would certainly expect a popup - in my case a fileDialog - to be drawn on top of everything else. Yet, it's drawn behind any of my sprites with +ve z-indices. Almost a year into my project I don't suddenly want to have to go in and start re-ordering everything else. It could take days.

Actually, I did find a workaround but only because most of the world I needed my dialog to be on top of was on the same script. I basically hid everything when the fileDialog came up then showed it again once the selection was made. If they were in different scripts you could easily run into the problem of circular references

func _on_OpenFileButton_pressed():
savedHandFileDialog.popup()
hostPanel.hide()
tableTop.hide()

func _on_SavedHandFileDialog_file_selected(path):
tableTop.show()
hostPanel.show()
savedHandFile.text = path

[YuriSizov]

One would certainly expect a popup - in my case a fileDialog - to be drawn on top of everything else. Yet, it's drawn behind any of my sprites with +ve z-indices. Almost a year into my project I don't suddenly want to have to go in and start re-ordering everything else. It could take days.

Does set_as_toplevel help your case?

[michaelpbl]

No, it didn't. I applied it to FileDialog, then to it's parent and then to it's parent( hostPanel), and none of them had any effect. The hostPanel which is being hidden and then shown is a sprite with z-level of 5 to make sure it appears on top of the world (in this case tableTop). My workaround however works beautifully for me.

[Thebas]

(No available z index on UI)
Hey guys! Finding this commonish use case difficult to solve. Any good solution?
This is the behavior I'm looking for but with the selected always on top of the others

Edit: So you know, using raise() as proposed

Structure:

P.S: set_as_toplevel is disastrous :D (it jumps to top left corner)

Possible workaround:
by bengtsts
"raise() and set_as_toplevel() affect the node's scene tree position. Lower nodes in the tree are drawn after those above so are drawn on top. Thus the issue in your first example. Raised nodes are pushed down a place in the scene tree changing the order appearing in the HBoxContainer. Thus the issue in your second example. Setting as top level means the node does not act as a child node so the container node doesn't behave as it's parent. Your last issue.
Here's a work around:
-add a sprite as a child to each button node,
-centre it to the button,
-set the button's self_modulate color alpha to zero so only the sprite is visible now,
-use z ordering on the sprites."

Results:

The code:

[PrestonKnopp]

@Thebas Good use case for z-index.

You can use the following to apply z-index to a control:

var item = control.get_canvas_item()
VisualServer.canvas_item_set_z_index(item, rect_scale.length() * 10.0)

Hope that helps.

[Thebas]

@Thebas Good use case for z-index.

You can use the following to apply z-index to a control:

var item = control.get_canvas_item()
VisualServer.canvas_item_set_z_index(item, rect_scale.length() * 10.0)

Hope that helps.

VisualServer.canvas_item_set_z_index(get_canvas_item(), rect_scale.length() * 10.0)

/\/\/\
(The solution I was looking for!)
Absolutely! Much more elegant. Thank you!

[Geometror]

I am currently working on this (godotengine/godot#68070) and would like to ask for some feedback. z_index related properties are moved to CanvasItem, so it can be used for both Node2Ds and Controls. There was the concern that a changeable z_index for Control nodes may induce some confusion (especially for inexperienced users) because that only changes the drawing order and has no influence on input processing. So the current implementation uses configuration warnings to prevent that.