Provide an approach for controlling the stack order of elements

[planger]

SVG uses the "painter's model" to determine the stack order of elements. That is, elements that are below in the SVG document model will be drawn on top of the already drawn elements (painting over already painted elements). Thus, also in Sprotty the order in the SModel essentially defines the stack order (z-index), as the SModel is rendered top-to-down, depth-first.

With the BringToFrontAction, we additionally can move elements to the end of the SVG document and thus put them on top. However, this only works within the context of a single parent element. An element can only be pushed to the top within the z-index of its parent, because its parent isn't moved in the SVG document.

These are the most common use cases for controlling the stack order I'm aware of:

• Bring to front on selection: This is nicely covered by the BringToFrontAction, maybe it can be made recursive to also bring an element's parents to the front to ensure the selected element is really in the front also in nested scenarios.

• Visual feedback and "control shapes", such as resize handles: Those are elements which are added to the SModel for a certain purpose, such as showing ghost elements while creating elements (e.g. while edges are drawn) or to provide a UI to move, resize or re-parent elements.
  

• Decorations: These are usually additional elements added as children of certain elements to annotate them with additional information.
  

Partly, the issue with visual feedback and control shapes can be circumvented by recursively dispatching a BringToFrontAction, as there usually is only one element that is currently edited and there is little chance of having to coordinate the stack order among multiple elements. However, it sometimes is somewhat cumbersome to handle, e.g. to move an element from one container to another one, we have to take out the element of the SModel hierarchy and re-add it to the root manually, to ensure it is painted on top.

For decorations, it may become more involved as there may be several decorations. Guaranteeing that all are on top may become a rather complex computation to determine an order in the SModel that ensures that. I guess in certain nested scenarios it may even become impossible without breaking out of the hierarchy.

We are happy to work on this topic and there are a few ideas floating around (ranging from introducing dedicated layers in the view to at least encapsulating the workarounds into framework features), however, I wanted to collect some feedback and ideas for a sustainable solution before starting with an implementation. WDYT?

Thanks a lot in advance!

[spoenemann]

Adding a layers would be a very powerful concept, but also introduce a huge amount of complexity. Generally I'd be fine with encapsulating low-level operations like reordering elements to control z-order into higher level actions. Applying that to parents when necessary in nested graphs could be an option to those actions.