eclipsesource / papyrus-gefx

A new Editor kind for Papyrus, based on GEFx and GMF Runtime
0 stars 2 forks source link

[Renderer] Improve layout consistency when using shapes #39

Open CamilleLetavernier opened 5 years ago

CamilleLetavernier commented 5 years ago

This issue has found while working on #16 and will mostly affect cases where the shape is changed dynamically (Which isn't the typical case - in standard UML the shape is related to the type of semantic element, e.g. Package or Comment, and will never change after created).

When using a standard Region, the border will affect the layout (Border width is involved in inner size computation). However, when using Region#setShape, the Border is applied to the visual shape, but is no longer taken into account for layouts. The result is especially visible when we increase border sizes:

image

On packages in the left column (Package Shape), the border doesn't affect the position of the label, which is then hidden under the border. In the right column (No Shape), the border affects the position of the label, which remains readable in all circumstances (Making the package bigger when necessary).

This layout inconsistency causes the Package to jump around when switching from the Package Shape to the Rectangle shape (The bigger the border, the worse it becomes)

I'm not sure yet what the best solution would be; but we definitely want consistent results

Package also highlights the "worst case scenario" in that it will need twice as much vertical space for its borders in its Package Path form (Above and Below the tab) compared to its square form, but other simpler shapes are also affected by the layout inconsistency. For example, comments:

image

CamilleLetavernier commented 5 years ago

An option would be to keep the main figure (VBox) as-is, maybe just using transparent values for background and border colors, and stack it on top of a shape-region with the same size. So layout would be handled by the VBox and Shape by the Region when present.

In general, having a StackPane rather than a VBox could provide more flexibility (Although I'm a bit worried about adding intermediate StackPane containers on all node content parts). The problem is that once the visual is set for a ContentPart, we can't change it, so we can't simply add an intermediate StackPane on-the-fly when necessary.

Current structure for NodeContentPart:

Suggested structure change:

CamilleLetavernier commented 5 years ago

The approach above might conflict with pick-on-geometry behavior, since the VBox and StackPane would know nothing about the Background Shape. We'd have to consider picking only on the Shape Region when it's present, and only on the VBox otherwise.