| [elk-dev] Meeting Minutes 2015-09-07 |
Hi everyone, here's the minutes of our first meeting I promised to send around. There are a few open problems we can think about in private and discuss sometime next week. Feel free to reply with any corrections you may have, especially concerning our discussions on hyperedges. Cheers, Christoph Daniel =================== ELK Project Meeting =================== September 7th, 2015 14:30--17:00 Attendees: - Christoph Daniel Schulze (minutes) - Ulf Rüegg - Miro Spönemann - Nis Wechselberg Topics: - How to Run the Project? - Meta Model - Plug-ins and Restructuring - Layout Features Next Meeting: - Properties - Logging - Inclusion of Sequence Diagram Layout Algorithm How to Run the Project? ======================= Project Website --------------- What is there that can be a project website? - The official Wiki (wiki.eclipse.org) - Project-run website (elk.eclipse.org) DECISION: We shall use a custom project website that uses the default template for now. DECISION: We want a developer mailing list. DECISION: We need to have a newsgroup. DECISION: We will also idle in #kieler or #elk? Documentation could be written with GitHub Markdown and put in a repository. An HTML version would then be generated with Jekyll and uploaded to the project servers. Gerrit ------ Instead of Gerrit code reviews, it's possible to use GitHub pull requests. DECISION: We want to use GitHub pull requests! Oomph ----- DECISION: At some point, we want an Oomph installer that also installs test-relevant stuff such as the KGraph synthesis and KLighD. Bugzilla -------- DECISION: Create one component per layout algorithm, as well as one component for the infrastructure. Automatic Build --------------- DECISION: We use our Bamboo build infrastructure and push the results to the Eclipse download servers. Meta Model ========== New Structure ------------- DECISION: We basically use the new version of the model produced for my latest talk, with the exception of the changes outline in the section on Hyperedges. DECISION: Since nodes, ports, and labels now _are_ KShapeLayouts instead of _having_ KShapeLayouts, the "getData(...)" method will for backwards compatibility check if a KShapeLayout was requested and, in that case, return "this". Similarly for KEdgeLayout. QUESTION: Can we configure the EMF generator such that it uses the basic EMF model implementations? What consequences would this have? QUESTION: How important is it to us to keep opposite references? They cause problems with Xtext. Hyperedges ---------- DECISION: While we're at it, we want to try and add support for hyperedges in the graph structure. This needs to be done in a way that causes the least amount of changes for old code as possible. DECISION: Hyperedges are implemented into the graph structure by giving a KEdge a list of sources and targets. We add a method isHyperedge() to check if an edge is a hyperedge (sources.size() > 1 || targets.size() > 1). We also keep legacy "getSource()" and "getTarget()" methods around that return the first node in the list of sources / targets, respectively. PROBLEM: How are source ports mapped to source nodes (and target ports mapped to target nodes)? PROBLEM: If a KEdge has multiple source nodes, we cannot use the source node as a containment for the edge anymore. One suggestion was to add a list of edges to each node and add an edge to the node its coordinates are interpreted relative to. DECISION: To store routing information for hyperedges, we give the KEdgeLayout a list of "KEdgeLayoutSegment"s. Segments can be outer segments or inner segments. Outer segments connect to a node / a port. Inner segments are surrounded by other segments. Each segment thus has an optional source and / or target KShapeLayout, a start point, an end point, and a (possibly empty) list of bend points. DECISION: The old "getSourcePoint()", "getTargetPoint()", and getBendPoints()" methods will be kept around in KEdgeLayout and will simply forward to the corresponding methods of the first edge segment. If an edge is not a hyperedge, the first segment captures all routing information. Backwards Compatibility ----------------------- The new structure will make our KGX files obsolete. This is not really a problem, though. The old model can still hang around and be used to write a conversion. Properties ---------- PROBLEM: Developers can set miscellaneous object properties on KGraph elements. This is not compatible to EMF serialization and deserialization. Will be discussed on the next meeting. Plug-ins and Restructuring ========================== Names ----- KGraph - ELK Graph KIML - ELK Core Structure --------- elk.graph A plug-in that contains all the basic graph-related structures. This would include some of the stuff in kieler.core, such as KVector. elk.graph.text Xtext grammar and related classes. elk.core The core infrastructure of ELK (what we have so far come to know and love as KIML). elk.<algorithm name> Layout algorithms provided by ELK. Plug-ins -------- kiml - ELK kiml.config.text - KIELER kiml.export - KIELER kiml.formats - KIELER (for the moment, at least) kiml.gmf - ELK kiml.grana - KIELER kiml.graphiti - ELK kiml.graphviz - ELK kiml.ogdf - KIELER kiml.service - ELK kiml.ui - ELK klay.force - ELK klay.layered - ELK klay.planar - KIELER klay.tree - ELK kwebs.server - KIELER Layout Features =============== Layout Configuration -------------------- Miro argues that the full-blown configuration may be way too complicated. There are ways to influence layout options through preferences, extension points, custom layout configurators, ... Understanding this is quite complicated to understand. Miro advocates a programmatic approach, where people configure the graph they build with the appropriate layout options. Ulf argues that we may not be able to get rid of VolatileLayoutConfigs. DECISION: Once ELK is filled with source code, Miro will go over the configuration interface Preference Page --------------- DECISION: We want to get rid of the "Default Layout Option Values" table on the KIML preference page. DECISION: We want to get rid of the "Oblique edge routing" option. DECISION: We will have to investigate whether the "Animate layout" and the "Zoom to fit after layout" options are necessary. They seem like options that are specific to a given editing framework...
Attachment:
signature.asc
Description: OpenPGP digital signature