Community
Participate
Working Groups
See https://polarsys.org/forums/index.php/mv/msg/307/1066/#msg_1066 for some context. In summary, ELK mostly works "out of the box" on Sirius diagrams, giving much better results that the default "Arrange All" algorithms in many cases. However, because ELK works at the generic GMF level, it has no knowledge of some Sirius-specific constraints. The resulting layout can thus cause problems with the rest of Sirius, which expects these constraints to always hold. One such point concerns border nodes ("ports"), whose position after an ELK layout do not match what Sirius expect in normal operation. The mismatch then causes some Sirius features to be broken/disabled. The scope of this ticket is to identify all such issues, discuss and analyse them, and if possible fix them (in Sirius and/or in ELK, depending on the details). This is not about deep integration of ELK in Sirius (which would be nice, but is another kind of work). The goal here is to be able to run ELK algorithms on Sirius diagram as an external tool to get the improved layout, but still get a fully functional Sirius diagram afterwards.
One known issue is that after an ELK layout, the "Straighten to" command on edges with ports can not be executed anymore. It seems that ELK shifts the GMF-level positions of the ports in a way that StraightenToCommand.canExecute() does not expect, which makes canExecute() return false for these. The problem is not visible immediatly because even though the GMF-level coordinates are broken (from the point of view of Sirius), the DBorderItemLocator which works at the Draw2D level "fixes" them and displays the bordered nodes at the expected location.
I created a post [1] an ELK forum about port location aspect. [1] https://www.eclipse.org/forums/index.php/m/1749900/#msg_1749900
New Gerrit change created: https://git.eclipse.org/r/117685
New Gerrit change created: https://git.eclipse.org/r/117775
New Gerrit change created: https://git.eclipse.org/r/117964
New Gerrit change created: https://git.eclipse.org/r/117963
Gerrit change https://git.eclipse.org/r/115989 was merged to [master]. Commit: http://git.eclipse.org/c/sirius/org.eclipse.sirius.git/commit/?id=866e12d3c9c48529d32ef856956298f053bb8cdf
Gerrit change https://git.eclipse.org/r/117685 was merged to [master]. Commit: http://git.eclipse.org/c/sirius/org.eclipse.sirius.git/commit/?id=ca5a79711048c86fd7d0dfe05c98b036660fd6c1
Gerrit change https://git.eclipse.org/r/117775 was merged to [master]. Commit: http://git.eclipse.org/c/sirius/org.eclipse.sirius.git/commit/?id=dea99f00f9234993dbe89cccc9cf0fb4a5b88287
Gerrit change https://git.eclipse.org/r/117963 was merged to [master]. Commit: http://git.eclipse.org/c/sirius/org.eclipse.sirius.git/commit/?id=5d91fd395ffac08c50ad6aa36329a24a9e9a6826
Gerrit change https://git.eclipse.org/r/117964 was merged to [master]. Commit: http://git.eclipse.org/c/sirius/org.eclipse.sirius.git/commit/?id=f7513dac9aa9dacd68354f4cd9bd834ae07b5756
New Gerrit change created: https://git.eclipse.org/r/118650
Gerrit change https://git.eclipse.org/r/118650 was merged to [master]. Commit: http://git.eclipse.org/c/sirius/org.eclipse.sirius.git/commit/?id=4088ca72db02c58e87641fd3d58016ce4cb8758a
New Gerrit change created: https://git.eclipse.org/r/118759
Note that the bulk of the integration work is already here and will be testable in M6, but this is still an early version with known bugs/limitations and many possible improvements. Work on this will continue after M6.
New Gerrit change created: https://git.eclipse.org/r/119095
New Gerrit change created: https://git.eclipse.org/r/119333
Gerrit change https://git.eclipse.org/r/118759 was merged to [master]. Commit: http://git.eclipse.org/c/sirius/org.eclipse.sirius.git/commit/?id=d95ca07b549a29e20124ad57b2cd26ae1f5b71e6
Gerrit change https://git.eclipse.org/r/119333 was merged to [master]. Commit: http://git.eclipse.org/c/sirius/org.eclipse.sirius.git/commit/?id=f576295650cb2736dd45f8a1a330251d72cf22b6
New Gerrit change created: https://git.eclipse.org/r/120254
We should probably include the ELK documentation in our update-site, or at least the part of it that it is needed for specifiers to understand the different algorithms provided by ELK and how the configuration parameters impact their behavior. It looks like https://www.eclipse.org/elk/reference.html is a good entry point, but I'm not sure the web site is packaged as an Eclipse Help plug-in. Maybe just a clear pointer to that website is the best we can do.
(In reply to Pierre-Charles David from comment #21) > It looks like > https://www.eclipse.org/elk/reference.html is a good entry point, but I'm > not sure the web site is packaged as an Eclipse Help plug-in. Maybe just a > clear pointer to that website is the best we can do. Nope, we do not package it as an Eclipse Help plug-in. It is a simple website generated using Hugo. Feel free to point to the website. Since release 0.3.0, we publish a ZIP archive that contains the website for each release. Depending on whether you depend on releases or on our nightly build, that might be something to look at?
Gerrit change https://git.eclipse.org/r/119095 was merged to [master]. Commit: http://git.eclipse.org/c/sirius/org.eclipse.sirius.git/commit/?id=4cd1686e522a91d0a1ab206ea23331bd45e38a05
New Gerrit change created: https://git.eclipse.org/r/121331
Gerrit change https://git.eclipse.org/r/120254 was merged to [master]. Commit: http://git.eclipse.org/c/sirius/org.eclipse.sirius.git/commit/?id=e87edce839fe87d3735af37353a5a4c2047d1707
Created attachment 273732 [details] Ecore sample ELK * Import the given project * Open the representation * Perform an arrange all * The EPackage1 and EPackage2 keep their original size => KO. The ELK new bounds are overridden later during the arrange all.
There is a NPE if I launch the above steps to reproduce without the plugin org.eclipse.sirius.diagram.elk activated. The corresponding stack, when launching the Arrange All is: org.eclipse.core.commands.ExecutionException: While executing the operation, an exception occurred at org.eclipse.core.commands.operations.DefaultOperationHistory.execute(DefaultOperationHistory.java:496) at org.eclipse.sirius.diagram.ui.tools.internal.editor.DDiagramCommandStack.execute(DDiagramCommandStack.java:71) ... at org.eclipse.gmf.runtime.diagram.ui.actions.internal.ArrangeAction.doRun(ArrangeAction.java:278) ... Caused by: java.lang.NullPointerException at org.eclipse.sirius.diagram.ui.internal.layout.GenericLayoutProvider.getGenericLayoutProvider(GenericLayoutProvider.java:89) at org.eclipse.sirius.diagram.ui.internal.layout.GenericLayoutProvider.provides(GenericLayoutProvider.java:46) at org.eclipse.sirius.diagram.ui.tools.internal.layout.provider.LayoutService.getProvider(LayoutService.java:95)
Gerrit change https://git.eclipse.org/r/121331 was merged to [master]. Commit: http://git.eclipse.org/c/sirius/org.eclipse.sirius.git/commit/?id=8c12ea816f9f8e4a1f71c3bf0b5c2a6e5b662654
Beside the NPE mentioned above and the related enhancement in bug #533553, there is still work to do on the documentation, notably for the newly introduced extension point.
New Gerrit change created: https://git.eclipse.org/r/122353
It's a minor issue, but the description fields of the ELK layout and layout option elements, which can contain significant amount of text, are serialized in the VSM. It would be nice to avoid this. If it requires too much work to be done before 6.0 please open a separate enhancement request to handle this in 6.1.
New Gerrit change created: https://git.eclipse.org/r/122596
Gerrit change https://git.eclipse.org/r/122353 was merged to [master]. Commit: http://git.eclipse.org/c/sirius/org.eclipse.sirius.git/commit/?id=b00bb1589bae98f71f4325c87a620bf47b917f52
Gerrit change https://git.eclipse.org/r/122596 was merged to [master]. Commit: http://git.eclipse.org/c/sirius/org.eclipse.sirius.git/commit/?id=ba8733ba88ec0b826e777d71164ce68fb9fc619c
Closing as the basics of the integration are here, even if it's still experimental. Remaining issues and enhancement requests should be treated by separate tickets.
Known issue: With the ecore sample, Their is still an issue. The padding in containers (EPackage) is not enough and the sub node (EClass) can overlap the container label.
(In reply to Florian Barbin from comment #36) > Known issue: > With the ecore sample, Their is still an issue. The padding in containers > (EPackage) is not enough and the sub node (EClass) can overlap the container > label. * there is
Available in Sirius 6.0.0, see https://wiki.eclipse.org/Sirius/6.0.0 for details