Right on schedule, Eclipse Sirius Web 2023.3.0 is now available.
You can get it from GitHub and build/deploy it yourself.
Here are the highlights of this version. You can find more details, including more technical-oriented changes in the complete changelog.
Project Templates
We have improved the user experience with a redesigned Projects Browser. It now offers support for project templates to create ready-to-use projects in one click. The project browser displays cards with all the possible ways to create a new project: invoke one of the available templates, create a blank (empty) project, or upload the contents of a previously exported project from a local archive.
When invoking a template, the newly created project will automatically be populated with models, and possibly with already-created representations:
Project templates are defined in the backend in Java, so they are very flexible in how they fill the initial content of the new project.
The UI displays the first few templates directly, but a dialog can be used to browse all the available templates if there are more available:
Free form compartment
We now support more complex layouts for nodes in diagrams with free-form compartments. It was already possible before to configure a container node to present its children as a list of items like this:
It is now possible for these children to be themselves containers with their own children freely layouted inside, unlocking powerful layouts like this:
Here the “Eclipse Foundation” container has three direct children (“GitHub”, “Sirius Web”, “Contributors”) which are configured as free-form compartments and display their own children.
This can be achieved by configuring the top-level node (“Eclipse Foundation” in the example) with the List layout strategy. This makes it place its children in a vertical list. The intermediate nodes (“GitHub”, “Sirius Web” and “Contributors”) are themselves using the Free form layout strategy:
Note that this feature is considered experimental at this point, so not all combinations of parents and children styles and layout strategies are supported.
Direct edit of the start and end labels of an edge
We already supported up to three different labels on edges: the main “center” label, and one on each end (close to the source or target nodes of the edge). However, the edition of these labels from the diagram was only supported for the center label.
This is now fixed, and it is possible to configure separate Label Edit tools for each of the labels on an edge. All three are optional, and support the Initial Direct Edit Label Expression which will be used to compute the initial value of the label when the edition will be triggered.
In order to edit the begin or the end label of an edge, it is necessary to double-click on said label.
Using F2 or the Direct Edit tool from the palette when the edge is selected will still trigger the edition of the center label of the edge, as before.
View edit begin label in action
Moreover, two new variables semanticEdgeSource & semanticEdgeTarget are available. They reference the actual semantic elements at the source and target of the edge. They are available both in the Initial Direct Edit Label Expression and while evaluating the behavior of the tools themselves.
Collapsing/expanding nodes
Nodes can now be collapsed or expanded. This capability is optional and must be enabled in the node’s configuration. For diagrams that use the classical odesign configuration from Sirius Desktop, nodes using the Horizontal or Vertical stack layout are automatically configured to be collapsible.
Collapsible nodes get a new “Collapse” tool in their palette. Invoking the tool on a node will remove its sub-nodes from the diagram. It does not change the underlying semantic elements, the operation only impacts the diagram’s rendering.
Once a node is collapsed, it can be reverted to its previous state using the “Expand” tool in its palette.
The current collapsing state of a node is available as a variable named collapsingState, which can be used to compute the node’s style. As a result, it is possible to create a conditional style that will use the collapsing state quite easily. In our diagram configuration, we can use the expression aql:collapsingState.toString() = 'COLLAPSED' as a condition to create a style that is used when the node is collapsed. In our example, the “Specifier” node switches from a plain grey rectangle when expanded to an image when collapsed.
Labels auto-wrap
Since 2022.3.0, it is possible to create multi-line labels by inserting “newline” characters directly in the label’s text value (e.g. using Shift-Enter during direct edit), but this requires an explicit operation and a modification of the label’s value itself.
Long labels inside nodes are now automatically wrapped into multiple lines as needed to respect the node’s width.
Explorer toolbar
It is now possible to disable (and of course re-enable) the synchronization between the explorer and the current selection.
When synchronization is enabled, if the user selects an element inside a diagram, the explorer view will ensure that the corresponding semantic element is visible and selected. This can require expanding new tree items which were previously not visible or scrolling the explorer’s view. When moving between elements in a diagram, this can quickly result in an explorer view with many tree items expanded, which can be confusing.
The new toggle button in the explorer can be used to disable this synchronization. When synchronization is disabled, tree items that are already expanded in the explorer will still be selected, but no new tree items will be automatically expanded.
As part of an ongoing effort to simplify the UI, we have moved the "New Model" and "Upload model" actions, into the new explorer toolbar. They were previously available in the project’s menu in the page header, and are now much closer to the elements they operate on.
Explicit behaviors in diagram descriptions
If a diagram description does not explicitly configure a delete/direct edit/element creation tool, the corresponding behavior is now simply not provided. Previously, we provided by default a canonical behavior. It was thus impossible to completely disable these behaviors.
Newly created nodes, edges, and tools are now explicitly configured to invoke the default canonical behavior. It is just made explicit in the model and can now serve as a base or removed to disable the behavior.
In the example below, Entity1 Node has:
- the default behaviors for deletion (1),
- label edition (2),
- and node creation (3) which were automatically filled when Entity1 Node has been created.
- Note that in Entity2 Node, the Delete configuration has been deleted. This disables the corresponding tool for these nodes.
See you in 8 weeks for the next version, which will be v2023.4.0, to be released in the last week of April. It will include many small fixes and improvements (“paper cuts”) which should provide a smoother user experience, and lay out the foundations for an improved diagram layout.
Thanks to all our valued customers, we truly appreciate your involvement in sponsoring the Sirius Web open-source project! If you want to join us and become a Sirius Web backer, send me an email, or contact the team.
