Z-Index should affect Input Order

[yosimba2000]

Currently, the hierarchy order of UI elements determines the draw order and input order. Changing Z-Index will change draw order, but never the input order. This is very unintuitive and makes designing UI a bad experience.

Scenario 1

1. Button A sits high in the hierarchy and covers the whole screen. Z-Index is unmodified.
2. Button B sits low in the hierarchy and covers the whole screen. Z-Index is unmodified.

Button B is drawn on top of Button A, and Button B receives input.

Scenario 2
Now, keep the hierarchy positions but adjust Button A to have a higher Z-index.

1. Button A sits high in the hierarchy and covers the whole screen. Z-Index is 1.
2. Button B sits low in the hierarchy and covers the whole screen. Z-Index is 0.

Now Button A is drawn on top of Button B, but Button B still receives input even though Button B is "invisible".

Why this is bad:
No user expects to select UI elements that are invisible to them. They expect to select what is visible. If a button is drawn on top, then it's only natural to expect them to be able to click it, and not some random button hidden behind.

Also, UIs are often toggleable. If you want to toggle a UI, you cannot just design its draw order. You have to design both the draw order with Z-index and input order by adjusting the hierarchy position. This means we need to design some sort of data structure to keep track of every single UI toggle state, their draw order and input order.

Imagine a Game UI and a full-screen Pause Menu. When displaying the Pause Menu, is the developer expected to disable the Game UI just to ensure that inputs go towards the Pause Menu instead of the Game UI? If there are more UI, the developer needs to keep track of each UI's current state, disable every single one except for the Pause Menu, then loop through all UI and restore their original state when closing the pause menu. All of this just to ensure the right UI gets the input.

All of this can be alleviated if the Z-Index controls the Input Order.

[Mickeon]

Currently, the hierarchy order of UI elements determines the draw order and input order. Changing Z-Index will change draw order, but never the input order. This is very unintuitive and makes designing UI a bad experience.

It's why changing the Z-index is highly discouraged already (there used to be a configuration warning about it). It was always technically possible to change a Control's Z-index, but the option was "hidden" in 3.x, exactly because of this reason.

No user expects to select UI elements that are invisible to them. They expect to select what is visible. If a button is drawn on top, then it's only natural to expect them to be able to click it, and not some random button hidden behind.

Exposing the Z-index to Control was also done because there was a desire to decouple the drawing order from the processing order. Reduz did say that it may have been confusing precisely for the reasons highlighted in your suggestion.

The Z-index is a property of CanvasItem, but receiving inputs is something that all Nodes can do regardless of their properties. Changing the way inputs are propagated breaks the existing expectations, breaks the workflow from the developer's perspective, and may potentially be expensive performance-wise (since all nodes would have to be sorted by priority before propagation).

Having any sort of input priority property is an interesting suggestion, but I am not personally convinced. Mainly, it may encourage building an "unorganized" UI scene. Input priority, process priority, and drawing order all jumbled up, instead of placing each CanvasItem in the tree in a more tidy manner.

[yosimba2000]

I see, thanks for the background info on the decision.

It'll just be a quirk I'll have to get used to. For now, I have found an easier workaround:

Since lowest-sitting nodes are drawn on top and given inputs first, UI that should be enabled is moved to the bottom of the hierarchy with MoveChild(-1) during runtime.

[timothyqiu]

When displaying the Pause Menu, is the developer expected to disable the Game UI just to ensure that inputs go towards the Pause Menu instead of the Game UI? If there are more UI, the developer needs to keep track of each UI's current state, disable every single one except for the Pause Menu, then loop through all UI and restore their original state when closing the pause menu. All of this just to ensure the right UI gets the input.

Making the Pause Menu's background a fullscreen control that blocks input would be enough I believe.