REQUEST: Make widget-depth inherited

[helmesjo]

This is pretty much the same issue as with old Unity 3 and the gameObject.active-states (which made no sense). It also makes no sense to not have the depth inherited, for example:

- A (depth 11)
-- Child1 (depth 1)
-- Child2 (depth 2)

- B (depth 10)
-- Child1 (depth 3)

In this case, I should really only have to adjust A or B to determine which is in front of which, and all the respective children should follow along (if A is infront of B, all As' children should be infront of B & it's children).

Another example is to have a child-widget behind it's parent, which shouldn't be possible. IMO, If you don't enforce this system people will just end up with poor layouts for their UI.

Basically, you should change the sorting-algorithm to take hierarchy into consideration. So you sort widgets "per level", having them only fight with their siblings. This should be doable without much impact on performance, preferably choosing an algorithm favouring small domains (I assume it will be some kind of "breadth-first" sorting).

Cheers!

[LightStorm]

I do not agree with this. Because there are many situations when child object should be behind it's parent. Also requested behavior will break compatibility with previous NGUI versions.
While I agree that the depth in the child object should automatically increase when we first add it in editor.

[helmesjo]

I do not agree with this. Because there are many situations when child object should be behind it's parent. Also requested behavior will break compatibility with previous NGUI versions.
While I agree that the depth in the child object should automatically increase when we first add it in editor.

Yes, it will indeed break previous scenes IF setup incorrectly. Think about it logically: If you put a piece of paper on top of another paper (as a child), why would you ever expect it to be behind the "parent"-paper? An if you put that parent-paper infront of a different paper (sibling-paper)... You get the point.

The reason why I put great emphasis on this is because it 1. makes a lot more sense (really, think about it) AND 2. it's also the way it's done pretty much everywhere (Android & iOS being good examples). With the current system, there is no logical order of stuff seen from a hierarchical perspective, thus making it easy to end up with a hard-to-maintain mess (having to individually walk through each widget, independent of the actual hierarchy, and adjust depths. This also creates insanely many depth-collisions).

Believe me, if it would have been like this from the start, you wouldn't see any issues.

Edit. Since there is the ability to have an invisible widget, no, there is no reason at all to render a child behind its parent.

[ArenMook]

There is no such thing as "set up incorrectly" in this case.

Imagine a button. Button itself is the background sprite (sliced sprite). It has a child that's a label. This one is +1 depth (so far so good, right?). But now imagine I want to add a glow effect behind this button on hover. I still want it to be a child of the button so that I can move it around and so I can anchor the glow to the button itself, but the depth must be lower than that of the button's sprite.

NGUI already increments depth by +1 every time you add a new sprite, but I will not be changing the way depth works for everyone. Cumulative depth is too restrictive.

Maybe as an optional feature, but certainly not for everyone.

[helmesjo]

There is no such thing as "set up incorrectly" in this case.

Imagine a button. Button itself is the background sprite (sliced sprite). It has a child that's a label. This one is +1 depth (so far so good, right?). But now imagine I want to add a glow effect behind this button on hover. I still want it to be a child of the button so that I can move it around and so I can anchor the glow to the button itself, but the depth must be lower than that of the button's sprite.

NGUI already increments depth by +1 every time you add a new sprite, but I will not be changing the way depth works for everyone. Cumulative depth is too restrictive.

Maybe as an optional feature, but certainly not for everyone.

Well, that's just like arguing for the case of not having inherited active-state for game objects... Of course there can be situations when you might "need" it, but that's only because you solved a particular problem in the wrong way to begin with. In your example, you should always have an invisible widget as base (AKA frame) if you think it might change (just like designing flexible code...), and setup the button from there on. If you enforce this, all is good an more people will be pushed to create good designs.
How is cumulative depth too restrictive? Having a background in both "native" Android & iOS development, I sure see only bad outcome with your solution (hard to maintain being a huge one). It's like your trying to reinvent the wheel a little here...

And again, you introduced "Invisible-widget", and that is all you need to solve any "problems" (pretty much everyone else does it this way). I can understand that it's a too breaking change for now (except optional), but I really can't agree with your other arguments.

But if you can't see this or it's a too big of a change, I'll settle for "Optional".

Edit. What I mean with "set up incorrectly" is that with your current solution, it is indeed more versatile but only for the bad. It's a more forgiving "okey you did wrong but it'll work anyways"-solution with the drawback that it's more complex to setup/maintain. With the one I described (again, used by Google, Apple etc.) you enforce a more strict and controlled way of setting up your UI, but can still achieve the same result.