ZIndex is a pretty neat tool as is right now, however it lacks a few tiny things that can make them a lot more easier to work with.
The ability to have more than 10 layers:
When making GUIs its pretty nice that you can set which has priority over the other, however while making a GUI which has a lot of “Elements?” in it, this could be rather limiting. I’ve noticed this with some GUIs a friend is making for a group game over ours and recently some GUIs I’ve made.
An option for the children to share same ZIndex as parent:
Currently, once you insert a new child it’ll have the default zindex of 1, however its parent for example may have 10. It would be helpful if we can have an option to make the inserted item have the same ZIndex as its parent. Currently we have an Auto Select option when using Advanced Objects, so maybe it can be something like that?
Well I’ve only really got 2 things, I recently started working on trying to get better with making GUIs and those are what I’ve noticed.
Edit: After few posts I thought I should add a poll
ZIndex is definitely removable, but I posted on that thread that the solution was to implement your second point. It’s super annoying to have children parented under ancestors every time you insert one, and that’s something that should automatically be fixed. If that was the case there’d be no need for more ZIndex values because with that setup you’d rarely go over 10. However, now that you mention Advanced Objects, I’m not sure this is the best solution.
Perhaps a better solution is to remove the cap on ZIndex (no need to arbitrarily limit if the limit can be removed) but also for GUI instances inserted through Advanced Objects to automatically have their ZIndex assigned to their parent’s. This would alleviate that issue, while also still allowing you to manually layer children under ancestors without having to use negative ZIndex values. If ZIndex values have no upper bounds, this would likely solve all issues regarding them.
The only issue I could foresee is inserting children to a frame, and then wanting to lower the parent’s ZIndex. This is actually an issue even currently. Now your children wouldn’t be layered as they were before – they’d still be on top, but not the same distance from the parent that they were before. If you automatically adjust the children ZIndex values when the parent’s changes from the property window though, you might cause unwanted frustration when the goal was to increase the distance between parent and children. @zeuxcg any thoughts on this?
this isn’t always a good thing. I have ImageLabel buttons, with a child ImageLabel as the “shadow” - the child has 1 less ZIndex than the parent. This is so the child will display below the parent, and I can have a button without having to make a shadow, then parent the button into the shadow.
I really hope they raise/remove the ZIndex cap soon, because @EchoReaper stated, their rendering code now supports it.
This might be considered unrelated, as what @Dev0mar is saying is to just use a sensible default. If your button’s ZIndex is 2 & you insert a new frame into it, the default ZIndex for the frame is 2 – but you can always change it to 1 to have it render below.
Slightly off topic
Also, even if they forced children to render on top of their parents, I still think that would be a good change. In a parent-child relationship, the parent should be the frame, and the child should be something within the frame. For a button & its shadow, sibling relationships make more sense. Here’s a post which specifically talks about that. http://anaminus.tumblr.com/post/38580091687/on-the-order-of-roblox-guis
Ah, makes much more sense! I love that idea![quote=“blobbyblob, post:6, topic:29690”]
For a button & its shadow, sibling relationships make more sense
[/quote]
Not entirely true. Why should I have to animate two objects, move/resize two objects, etc, when I could move the entire button as one whole object (which it is)
I suppose the solution to that would be making the shadow the parent, and the button itself a child of the shadow. In my mind that just sounds a bit odd - I imagine the shadow being a child of the button, not the button itself.
I’m also pretty sure that button clicks wouldn’t register on the button itself, only the shadow. Which is an issue. A solution to that would be to listen for clicks on the child element, not the parent layer (the shadow). Still seems a bit odd to me
local Button = Gui.Shop.ButtonVisuals -- would prefer Gui.Shop w/ Gui.Shop.Shadow as the shadow
Button.MouseButton1Click:connect(ButtonClicked)