392: Add structured nodes to the Workflow example

[CamilleLetavernier]

• Introduce Struct compartment with an X/YLayout (Freeform)
• Add a custom VBoxLayout that supports both automatic (based on content) and manual resizing
• Disable the collision movement restrictor in Workflow Example (Improve collision detector to work with Structured Nodes glsp#394)

This PR depends on the corresponding server changes eclipse-glsp/glsp-server/pull/129

Note that the PR still contains the debug "construction lines" for the compartments, to highlight the shape of the compartment. It can be turned off by removing the class-debug={true} from StructureCompartmentView in compartments.tsx. It was probably not necessary to introduce a new CompartmentView, but having decoration-support for Compartments can be helpful (And for future improvements, the compartment could have a different style from the parent Node, e.g. different background or specific borders, to separate the Header from the Compartment area).

Regarding the custom LayoutRegistry, it should be considered a placeholder, until we can integrate the changes from Sprotty (See eclipse-sprotty/sprotty/issues/232). Once we update to the latest version of Sprotty, it can be removed.

The new VBox layout was intended to replace the original Sprotty one (With the same set of features, plus a few new parameters), however it turned out a bit more complicated than expected. Also, I didn't have enough use cases in the Workflow example to fully test it (Especially, we don't have list-compartments examples, or multi-compartment examples). So, I could only test it with a very simple case (Activity Nodes) and the new Structured Nodes (Categories).

Collision Movement Restrictor has been disabled in the Workflow example, because in its current state, it prevents manipulating nested nodes (Which always collide with their parent/children). I've opened eclipse-glsp/glsp/issues/394 for follow-up improvements.

The new Category nodes can be connected with Edges (From/To Tasks or other Categories), which can be used to reproduce the issue from eclipse-glsp/glsp/issues/224. No fix for that yet, though :)

In terms of model, the main change is the extraction of layout-specific parameters in a new (optional) "LayoutData" attribute. There are multiple reasons for this:

• In Sprotty, by default, nodes have a Size and a Position, which is used both as input for layouting, and as output from the Layout algorithm. This is fine when nodes can be either Automatically resized, or Manually resized, but not both. In our case, the user-defined size is used as a minimum size, but the Layout can expand the node further when required. So, it was necessary to introduce new attributes (Specifically, LayoutData.prefSize, in addition to BoundsAware.size)
• LayoutOptions could have been a good choice for that, but they are inherited by child nodes. It makes sense for some of these options (Like alignment), but is not a good fit for node-specific layout options (Such as size). Having a separate attribute makes it easier to distinguish what can be inherited, and what shouldn't.
• We could have added this as a root property (e.g. directly under Node), but I think we'll need to add more attributes there in the future. For example, we may have the same issue with X/Y coordinates when introducing padding inside of the Compartment (Currently, padding can be added between the Node and the Compartment, but not inside of the Compartment). For more advanced use cases, we may also want attributes such as Min/Max size, etc. So, having a single place where these attributes can be added seems to be a more future-proof choice

Finally, there are still several issues with this PR, as the goal was to introduce nested nodes in the Workflow example, to provide a reproducible example for solving bugs related to nested nodes, and to implement extra features such as reparenting. Especially, this branch does not include reparenting. At the moment, the only supported interactions for structured nodes are Create, Delete, Move and Resize.

[CamilleLetavernier]

[martin-fleck-at]

@CamilleLetavernier I had a look at the code, fixed some minor issues and rebased it. There is still an issue with Sprottys implementation of the layout registry so I had to add a custom one to allow overriding layouts which we do for the 'vbox' layout. Other than that the code looks good!

However, I am a bit concerned about the usage of 'layoutData'. In my opinion this is basically the same as 'layoutOptions' which are already provided by sprotty and for which we already have our customizations. I don't think we should introduce yet another mechanism but instead should stay as close as possible to sprotty. I think interpretation of the options is part of the layouter. So if we think a property should not be inherited, we simply do not go through the parent hierarchy using the default getLayoutOptions method. Instead, I just added a new getElementLayoutOptions method to restrict the options to the specific element. I added this is a separate commit so it can be easily undone but I think it is worth having that discussion.

[martin-fleck-at]

Looks good to me, thank you for the update Tobias!