zlayer (continued)

[emilk]

Closes #1516.

Most of the work done by @mxsdev

Continuation of #2482

[mxsdev]

Hey, sorry for not getting to this when you got back! I got a little busy this week so it was pretty unfortunate timing. Thanks for taking care of it - feel free to lmk if there's anything more you'd like from me.

[emilk]

Oh no worry at all, I was just curious to try this out a bit :)

I tried yesterday putting panel frames on a negative Z layer so that widgets could use a smaller negative Z to paint behind other widgets, but it didn't work on my first go, and then I got distracted by something else… I would like to get something like that tried and working before merging.

[mxsdev]

@emilk

Gotcha! If I recall correctly, with this implementation ordering happens only within the same layer id - that is, Z-ordering determines the ordering within a specific layer. This is in line with the original proposal, which suggested including Z as part of PaintList, which (I think) determines the ordering within a layer. So, it's different than CSS z-order for example. So what you're describing, if I understand correctly, probably wouldn't work, since the panel and widgets are on separate layers. To do what you're describing, you'd have to put the widgets on the same layer, and use with_z to control the ordering per-widget.

If you want to control the ordering between layers, it becomes pretty complicated. For example, if a widget has z-order 1, but all windows have z-order 0 (and are on the same Order), then the widget will appear over all other windows. If you're making a node editor and want edges to appear beneath nodes, for example, then this behavior isn't desirable.

As a solution, we could introduce something like register_layer, so that you can enforce a specific layer order before adding anything to it. (I think that currently, layers aren't internally "registered" until you've painted/interacted with something on it). Then ZLayer is for ordering layers globally, and register_layer is for ordering layers locally. To paint certain widgets over other widgets, you'd register two layers and paint on each.

The only other solution I see is to have some kind of "scoping," that is to implement a tree structure among layers, or among UI children. So, everything in a window would be a member of the "window layer." This would allow you to order elements among themselves in a window, but would not allow you to, for example, paint something above all other windows.