Integrate the Eclipse Layout Toolkit (ELK)

[philip-alldredge]

integrating the Eclipse Layout Toolkit (ELK). The integration should provide the capability to automatically layout shapes and/or connections.

Some desired capabilities may not be possible with the current version of ELK. Investigation is needed. The desired capabilities are listed below.

• Add support for the Eclipse Layout Kernel(ELK). Out of the box Graphiti support is not optimal because it does not convey to ELK that features are docked and that some are grouped together(feature groups).
• Place input ports on the left and output ports on the right by default. Same for access and requires?
• Support both incremental and complete relayouts.

Experiments have been conducted with the Eclipse Layout Kernel (ELK) and the results are promising. However, until the integration is completed and further testing has been performed, it remains to be seen exactly how significant an improvement integrating the capability will provide. In any case, it is expected to be a large improvement in the case of laying out the entire diagram. The goal is to focus on the usage of the layered algorithm since that makes the most sense for our use case.

Once that integration is complete. The ELK based implementation will take over the responsibility of the automatic layout. The current option will just relayout the entire diagram. On the UI side, adding additional menu items to customize the layout operation are being considered. These options are TBD and will be limited by ELK restrictions and available resources

[philip-alldredge]

Implementation Details and Progress

• The initial version will not support laying out connections which reference the contents of feature groups. Since the Eclipse Layout Kernel does not support ports which contain other ports, it is not possible to represent the contents of feature groups in the Elk graph. On the ELK forums there has been mention of a dedicated edge routing algorithm in a future release. Once that is available, the editor can be updated to perform a separate layout pass for all connections. In this second pass, the feature group contents could be represented as ports. See https://www.eclipse.org/forums/index.php/t/1086846/
• Incremental Layout. The editor performs and incremental layout anytime an element is found that does not have a side or position. ELK does not support laying out a graph which has portions of it in a predetermined position. This is an issue for incremental layout. The planned implementation will provide 3 different user-selectable incremental layout behaviors. Each of them have their benefits and drawbacks.
  • Layout Diagram - Each time the editor needs to lay out an element, layout the entire diagram. This obviously has the drawback of a lack of control of the layout. However, for some users this may be the preferred setting. It provides a layout without crossing lines without manual layout work.
  • Layout Container - When an element is found that doesn't have a size or position, the element's container is layed out. This is nice so that when setting a classifier for a sub-component or expanding an element, the contents of that element are layed out properly. However, this will often change the size of the container or move features. In such cases the result is not optimal. In such cases being able to run a connection layout algorithm automatically would be helpful.
  • Layout Contents - This choice is the least likely to cause disruption to the user's layout. It simply lays out the contents of any element which does not have a size or position. Since this has the least potential for adverse reactions, this is the default setting. However, since the container is not layed out in many cases, elements may overlap with each other. They are placed in the same position to reduce the chance of automatically resizing the container. The user can manually layout the contents of an element using the context menu. This mode has a couple of special behaviors.
    • The first is that if a feature is added, it will be positioned after other features on the appropriate edge.
    • If none of the siblings of the element have a position or size, then the container is layed out. This is very beneficial when transitioning from hiding to showing the contents of an element. This is considered safe because there is no user layout that is being replaced.
• Layout Commands - The context menu will include a layout sub-menu which provides the user with the ability to layout the entire diagram or a selected element. The layout sub-menu will also contain the various alignment and layout commands that already exist.
• Connections to other connections. ELK does not currently support representing such edges in the graph.
• INCLUDE_CHILDREN vs SEPARATE_CHILDREN hierarchy handling. It is TBD which mode will be used. INCLUDE_CHILDREN allows the algorithm to support connections such as bindings which cross the hierarchy. In other cases SEPARATE_CHILDREN can produce subjectively better results.

[philip-alldredge]

In addition to the ELK integration work. We are also investigating methods for laying out just connections. This would increase the capability and such an algorithm would improve handling of feature groups and potentially connections between connections.

[philip-alldredge]

The currently pushed ELK integration code seems to work really well. However, due to the connection layout issues with relation to feature groups, the code that uses the ELK edge routing has been removed. If the implementation of the connection routing goes well, it will be used. If not, the ELK edge routing code will be used with the caveat that it will not work with feature groups.

The connection layout algorithm would also be highly beneficial by allowing the layout of just connections instead. The initial implementation of the algorithm will be designed to layout all connections contained in a diagram element. The reason is that the initial implementation will not handle avoiding overlaps and proper spacing with existing connections.

Another reason for the desire for an alternative connection routing mechanism is ELK does not support the concept of having an internal and an external connection point.

There are some UI refinements that will be made after the results of the connection layout implementation.

[philip-alldredge]

The connection layout algorithm is promising but there does not appear to be adequate resources to stabilize it. However, there may be a way to support feature groups with ELK. The position selected for elements appear to be deterministic as long as the appropriate properties are specified. Feature group can potentially be represented by simple features which have the appropriate sizing, positions, and spacing. The plan is to make a quick determination about the practicality of this approach and to proceed with implementation if so.

[philip-alldredge]

An initial version of the ELK integration is completed. It will be pushed and merged as soon as labeling in the UI is finalized and the user guide is updated.

There are some known issues which have been reported to the ELK developers.

Example of the results:

[philip-alldredge]

A separate connection layout option will not be implemented at this time. That is not supported by ELK.