LayerPosition

[smallB007]

Hi there,
What is the reason for having LayerPosition::FromBack and LayerPosition::FromFront instead of just LayerPosition?
I find that unnecessarily complicated. Positions are always(mostly?) given from the beginning of "something", here, a container. Even algorithms that search from back always(mostly?) give found position in relation to the beginning.

[gyscos]

Hi!

There are a few reasons for this:

• There is no "obvious" Z orientation. Should higher numbers be further away from the user? Closer? There is a general lack of consensus, all the way into 3D visualization software.
• At the implementation level, it is a "stack", which starts at the bottom, and higher numbers are higher up. The "front" view in the stack (the visible view) is actually the end of this stack (sometimes called the stack "back"). The "back" view (the one furthest back, closest to the background) is actually the start of the stack (sometimes called the stack "front"). So these two ways to represent values (either based on the view being front/back, or based on the container) are in opposition here. I decided to go with the view interpretation ("front" is what is currently active), since that's the most common concept in UI (for example "move to front" and "move to back" in various UI tools).
• Because we use "front" to mean the top of the stack and "back" to mean the bottom of the stack, using plain numbers to index views can be confusing (and as a matter of fact I believe this was the case initially and people did get confused). Is index 0 the currently active view? Or is it the furthest one back? Using obvious/explicit "strong types" like FromBack(0) and FromFront(0) helps removes this ambiguity.
• There is value in being able to represent "the furthest back position" or "the closest front position" independently of the stack size. If we only had FromBack (which effectively is the container's index), we would have to rely on the container length every time we want to represent something near the front. That number would also change as the stack change. Having a way to represent "the top-most view" or "the view right _behind" the top-most view" and have it stable regardless of the stack size is valuable.

[smallB007]

Thank you for the answer. As much as I understand your reasoning about it, I still believe giving position the way cursive does it is confusing. If you really wanted to have Front and Back meaning most front, i.e. visible and furthest back, i.e. at the very bottom, the first layer if you please you could provide convenience functions and be done with it. Giving positions the way it is done now it is not only confusing but also very unusual from the software API point of view. Tbh, I've never came across this way of describing position. Mostly (if not always) position is given with the relation of the beginning of the "container" it is in.
Anyway, thank you for the time to explain your reasoning, needless to say, I disagree with it and think that the design could be greatly simplified without loosing expressiveness.