| Re: [elk-dev] Meeting Minutes 2015-09-07 |
On 09/09/15 13:24, Miro Spönemann wrote:
> On 09.09.2015, at 13:07, Christoph Daniel Schulze <cds@xxxxxxxxxxxxxxxxxxxxxx> wrote:
>>> - 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).
>>
>> I don't see why this would result in compatibility with old .kgt files.
>
> At least structural compatibility, so you can run the layout algorithms on them. Not Compatibility of existing bend point coordinates, though.
I think I understand your point now. In old .kgt files, outgoing edges
are written as being contained in the node they are going out of, which
is not what the new model would expect (except if the edge connects to
one of the node's descendants). Thus, the new convention would interpret
existing bend points as being relative to that node instead of to its
parent, which would make them invalid. Running automatic layout again
would ensure that the bend points are given relative to the container,
which would then yield correct bend points.
That is true. If it's not much of a problem to add this kind of
flexibility, I'm all for it. I guess it would boil down to layout
algorithms calculating bend points and coordinates as they do now, but
calling a conversion method before applying the coordinates. The
conversion method would recalculate the coordinates such that they can
be interpreted relative to the container.
However, with our hierarchical layout approach this would only work if
the container is the node that contains the graph that is currently
being laid out, or one of its descendants. Example:
n1
-> n2
-> n3
-> n4
If layout is currently run on n2, an edge between n3 and n4 can be
relative to n3, n4 or n2. It cannot, however, be relative to n1 since
the position of n2 in n1 is not known yet. So the requirements need to
be slightly more complicated than what you proposed.
>>> - 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.
>>
>> We discussed that option, but the dependency management would have been
>> a nightmare since it's not trivial to derive Maven-compatible
>> dependencies from an Eclipse project's manifest file. We actually looked
>> at how Xtext manages this. It turns out that you keep a map from Eclipse
>> dependencies to the appropriate Maven dependencies. All in all, the
>> process is complex enough for us to opt for the much simpler one we have
>> settled for.
>
> Maybe we could at least add a dependency to EMF instead of including it?
Ulf just told me that during my vacation he and Carsten actually came
closer to publishing everything as separate bundles than what I knew
about, so my reasoning may already be obsolete.
Attachment:
signature.asc
Description: OpenPGP digital signature