| Re: [elk-dev] Meeting Minutes 2015-09-07 |
A few thoughts:
- We could call the core plugin org.eclipse.elk.kernel
- The source and target features of edges could refer to a common interface of ElkNode and ElkPort, e.g. ElkConnector. Then getSourceNode() would do something like
ElkConnector source = sources.get(0);
if (source instanceof ElkNode)
return (ElkNode) source;
else
return ((ElkPort) source).getNode();
This would solve the mapping problem between nodes and ports for hyperedges.
- We could loosen the coordinate system convention for edges and say that their coordinate system always corresponds to their container in the EMF containment tree. We could keep the existing convention regarding which node should be the container, but also support graphs where the convention is not met (shouldn’t be a problem). By this we would gain compatibility of old .kgt files, since the containment of edges would change with the new meta model (the default container of edges is not the source, but the parent of the source).
- Parsing properties from a persisted ElkGraph requires the layout options metadata, which is in the elk.kernel bundle. We should consider merging elk.kernel and elk.graph. Then we could more easily simplify the serialization / deserialization mechanism for ElkGraph properties. One approach: maintain a list (not a map) of key-value pairs, both strings. Additionally each such pair could have a transient field for storing the parsed value, which is loaded on demand. Whenever the value changes, it is immediately toStringed, so the list from which the serialized form is derived is always up-to-date. Advantage: no distinction between persistent and transient properties in the meta model. Disadvantage: worse runtime performance for getProperty(..) if there are many properties in the list, and possibly unnecessary toString() invocation if the graph is never serialized.
An alternative: keep the properties map transient and create another meta model that adds all the serialization-specific stuff. If you want to persist properties, use the derived meta model instead of the original.
- Instead of pushing a standalone library to Maven Central, we could push individual bundles (those not depending on Eclipse UI). Xtext does it this way.
> On 08.09.2015, at 11:15, Christoph Daniel Schulze <cds@xxxxxxxxxxxxxxxxxxxxxx> wrote:
>
> 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...
>
>
> _______________________________________________
> elk-dev mailing list
> elk-dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe from this list, visit
> https://dev.eclipse.org/mailman/listinfo/elk-dev
Attachment:
signature.asc
Description: Message signed with OpenPGP using GPGMail