Godot: Z-index for the Button node? Or... all Control Nodes?

[Qws]

Why is there no z-index for the Button node, Panel node and I believe all Control Nodes?

When I press on the button in my game, a panel should be sliding from out of camera view into the camera view. The panel should be beneath the button on Z-Index. But instead it overlaps the button.

But for some reason it doesn't has Z-index option. And from the other controls I've seen, none actually do... is there a particle reason for it?

I'm using Godot 2.1.2 Stable.

[reduz]

GUI, like most 2D in Godot, is displayed on tree-order. No index is
provided.

On Tue, Jan 31, 2017 at 4:19 PM, Qws [e-mail] wrote:

Why is there no z-index for the Button node, Panel node and I believe all
Control Nodes?

When I press on the button in my game, a panel should be sliding from out
of camera view into the camera view. The panel should be beneath the button
on Z-Index. But instead it overlaps the button.

But for some reason it doesn't has Z-index option. And from the other
controls I've seen, none actually do... is there a particle reason for it?

I'm using Godot 2.1.2 Stable.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/godotengine/godot/issues/7692, or mute the thread
https://github.com/notifications/unsubscribe-auth/AF-Z20Cgly1bZmAuOTfZLGNgVXDWP63kks5rX4lSgaJpZM4LzEAa
.

[27thLiz]

Note that you can still set the z-index for controls manually: some_control.set("z", index).

[AlexHolly]

Edit: Adding multiple CanvasLayers Solved my issue

I tried some_control.set("z", index) it looks like it has no effect I tried 2.1.2 stable and 3.0

I am using Sprites that have a z-index > 0 and the UI should be on top of the sprite but it looks like the z-index from control is 0 and there is no way to change it.

extends Control

func _ready():
    set("z", 2)
    $WindowDialog.popup()

I could probably solve this somehow with all sprites having a z-index<0 but it looks more like a missing feature or bug.

[jahd2602]

GUI, like most 2D in Godot, is displayed on tree-order. No index is provided.

Sprites are displayed on tree-order, but they have z-index that we can change to fine-tune without too many complications. GUI controls should also have that option.

[henriquelalves]

Giving my two cents here, but z-index should be a CanvasItem property, not a Node2D one (that way it would be editor configurable for both Control and Node2D).

[swarnimarun]

Has anything progressed o this topic?
And I like the idea of Z-Index being property of Canvas_Item. But the problem seems to be of the fact that z-index doesn't work in 3D but Controls work in 3D so how should it implemented.

[MrHoothoot]

This would be a nice feature. It adds more flexibility.

[reduz]

The reason why Z-Index is not exposed in controls is because it won't work
as you expect it to. The control may be displayed on top of other controls,
but as input is handled strictly in tree order, your control won't get
input by being on top of other controls.

If you want it to appear on top of others, use set_toplevel() instead, and
your control will not depend on the parent controls, as well as appearing
on top.

On Mon, Jun 25, 2018 at 8:36 AM MrHoothoot [e-mail] wrote:

This would be a nice feature. It adds more flexibility.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/godotengine/godot/issues/7692#issuecomment-399921542,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AF-Z2-KOfolb3uxXVjjB72en8CfRbtGMks5uAMtFgaJpZM4LzEAa
.

[eligt]

@reduz Is input handling the only reason for such limitation? I personally use lots of Labels and other controls exclusively for their display function while all input is handled higher up in a root node (as that's the only level at which input state becomes relevant). Unless there's a different way to display text that I'm missing, then I think it's quite cumbersome to limit z-sorting of UI elements just because of Input handling as 90% of use cases will be for display-only.

[raffomania]

So, given the following Tree:

  Sprite
GUIControl

When I set a z-index > 0 on Sprite, as well as Z as relative to true, Sprite still draws over children of GUIControl.

Given that Controls are drawn in tree order, shouldn't GUIControl draw over all children of SpriteControl, if they have Z as relative set to true?

[deepmax]

So, given the following Tree:

  Sprite
GUIControl

When I set a z-index > 0 on Sprite, as well as Z as relative to true, Sprite still draws over children of GUIControl.

Given that Controls are drawn in tree order, shouldn't GUIControl draw over all children of SpriteControl, if they have Z as relative set to true?

Is there any workaround for this?

[AlexHolly]

Like this maybe?

[razcore-art]

I see this is a long-standing discussion. I'll throw my 2 cents in cause I also found it unintuitive that you can't z-order Controls given they're supposed to be visual elements, apart from Containers. I understand that the reason is input handling. @reduz couldn't we then handle input in z-order and if same z-order in tree order?

I was doing something that requires this sort of layout, but I want to then place some nodes on top of others visually. It makes sense to me that they receive input on the visual order too (z-order) more so than tree order, if they were to have a z-order property.

This is the node setup:

When I do say this:

func _ready() -> void:
    get_child(3).set_as_toplevel(true)

It messes it up so that's not an option

As a workaround I see if I set TextureRects' show_behind_parent to true and then proceed to set one to false it visually does the job, so I guess that works, but then as I understand it, the input will still be processed in reverse tree order, I really think these properties should be considered for input.

edit: and what happens if we want the overlap to go from right to left? At the moment with it can't be achieved, unless done manually.

[KoBeWi]

If you put Control under Node2D, it will inherit its Z-index. That should be anough in most cases, UI is supposed to go on separate CanvasLayer anyways.

[sethboyles]

One issue with the z-index being tied to tree order is that for the various Containers, display position is also tied to tree order. Meaning if you have a Control that moves out of the bounds of its parent Container (say, in an animation), you have to no way of controlling which bordering elements it goes over or under, it will always go over elements to the left and under elements to the right (or above and below).

The Node2D solution doesn't work here, because then you lose the formatting of the Container.

[Calinou]

Closing in favor of https://github.com/godotengine/godot-proposals/issues/839, as feature proposals are now tracked on the Godot proposals repository.