[ELK] Improve routing style management when launching an "arrange all" using an ELK layout #333

lredor · 2024-03-21T17:05:30Z

As explain in the bugzilla 538933, the edge routing is currently not kept when launching a layout with ELK.

Steps to reproduce (with a more complete use case than bugzilla 538933):

Import projet ELKSample from ELKSample.zip
Open the diagram "new SimpleDiagramOblique". This diagram contains only edges with an "Oblique" routing style (with red color). It can be verified in the Appearance tab of the Properties view.
Launche an arrange all (ELK is set with Layered diagram and few parameters).
Expected: The routing style should be kept.
Observed: The routing style is kept. The edges are drawn graphically at right angle. BUT, each edge appears like "customized". The button "Reset style properties to default values" is enabled. This problem is not directly linked to the issue but must it will also be fixed. Warning: Even after the fix, the edge can appears as "customized" if the default font is not configured on your Eclipse like the use case ("DejaVu Sans" set in the Sirius diagram pref).
Open the diagram "new SimpleDiagramRectilinear". This diagram contains only edges with an "Rectilinear" routing style (with blue color). It can be verified in the Appearance tab of the Properties view.
Launche an arrange all (ELK is set with Layered diagram and few parameters).
Expected: The routing style should be kept.
Observed: The routing style is not kept.
Open the diagram "new SimpleDiagram". This diagram contains a mix of edges with an "Oblique" routing style (with red color) and edges with an "Rectilinear" routing style (with blue color).
Launche an arrange all (ELK is set with Layered diagram and few parameters).
Expected: The routing style should be kept, but not possible in ELK. The rule will be determine in this issue (see future documentation for more information).
Observed: All the routing styles are set to "Oblique". The edges, initially with Oblique routing style, are drawn graphically at right angle, and the edges, initially with Rectilinear routing style, are drawn with a straight line.

First technical analysis:
In the scope of bugzilla 548820 - "[ELK] Improve ELK graph transformation", a comment has been added in GmfLayoutEditPolicy to say that the routing style is on the parent edges's and not on each edges. In the scope of this bugzilla 548820, the routing style is set after the layout according to the routing style property value of the root element. But it is not automatically set according the routing styles of the edges in the diagram.

The goal of this issue is to kept, as much as possible, the initial edge routing style defined in Sirius.

This commit just migrates the data used by SimpleELKLayoutTest without any change. It also seems that some diagrams have not been refreshed according to previous modifications done on VSM file. All diagrams have been opened (and so refreshed) for this commit. Bug: #333

- 5 new representations have been added in tests data: - one with oblique edges, - one with rectilinear edges, - one with a mix of them and same number of oblique and rectilinear edges, - one with a mix of them and more oblique edges, - and one with a mix of them more rectilinear edges. - 5 tests corresponding to these representations have been added to check the routing style before and after the arrange all with ELK. Bug: #333

During the conversion from DDiagram to ELK Graph, the routing styles of original Sirius DEdge is now stored on the common parent of edges in ELK Graph. This property can be overridden by defining the routing style directly in the VSM. The tests have also been adapted. Indeed, before this commit the routing applied was always Rectilinear. Now, it is not the case. The existing tests have been "duplicated", to have the previous behavior (by forcing the "Rectilinear routing" in the VSM) and the new behavior for all existing tests by considering the initial used routing style. Bug: #333

Before this commit a StringValueStyle was created due to a bug in ELK that creates an empty list of junction points. This also causes, as side effect, an edge that seems to be "customized". Bug: #333

The representations created before the previous commit, that fixes the unexpected creation of StringValueStyle, can contain some kind of "empty StringValueStyle". The goal of this commit is to remove them. This commit also adds tests to check migration effect. Bug: #333