| [elk-dev] Meta Data Language |
| Hi elk lovers, here’s a proposal for an algorithm and layout options meta data language: The generated code is currently not checked in, so you have to run GenerateMetaData.mwe2 manually. We should decide whether to check in the code or not and then apply the same to the Graphviz Dot language. It’s not hard to generate the code during the auto-build: Furthermore, you will have to start a new Eclipse instance in order to use the meta data text editor. As soon as we have included the new plugins into the build, we can add them to the update site and include them in the Oomph setup so our developer instance will already have that editor. The file extension is *.elkm (use Ctrl/Cmd + Shift + R to find the meta data files). A Java file is generated into src-gen for each elkm file. For example, the class LayoutOptions is now no longer hand-written, but generated. Note how the linking between the elkm files and also between elkm and Java files works: - Ctrl/Cmd + Shift + R, type ‘Core.elkm' - Ctrl/Cmd + O, type ‘portConstraints’ - Ctrl/Cmd-click onto ‘PortConstraints' to navigate directly to the enum type Further observations: - Some enum options have an ‘UNDEFINED’ value (Direction, EdgeLabelPlacement, EdgeRouting, PortAlignment, PortConstraints, PortSide). We could remove those and set the default to null for the general option. Then we should make sure every algorithm that supports these options defines proper default values for them and uses the ‘duplicated’ keyword in its ‘supports’ declaration in order to generate a Property with overridden default value (see e.g. how this works for SPACING). Advantage: UNDEFINED would not be visible in the Layout view anymore. - Is there any reason for not merging the two Graphviz plugins into one? - The tree algorithm has plugin id org.eclipse.elk.alg.mrtree but package name org.eclipse.elk.alg.tree - How should we proceed with lower / upper bounds? For now I removed those from the meta data. I am thinking about introducing a more general approach of “graph validation”, which could be applied before any algorithm is executed. My feeling is that it would be more useful to throw an exception in this pre-layout phase instead of silently ignoring negative spacing values. If the source of the wrong values is programmatic, they should be fixed anyway. If the source is the UI (Layout view), ideally we should mark the wrong values there so the user gets an early feedback about nonsense configurations. - Now we’re ready to generate documentation for algorithms and layout options. What would be a suitable format for that? And is there additional information would we like to add into the meta data in order to enhance the documentation? Miro |
Attachment:
signature.asc
Description: Message signed with OpenPGP using GPGMail