Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [elk-dev] Meeting Minutes 2015-09-07
On 09.09.2015, at 14:58, Christoph Daniel Schulze <cds@xxxxxxxxxxxxxxxxxxxxxx> wrote:
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.

Yes, in that case the resulting coordinates will often be wrong (unless you do a full-hierarchy layout in one step). But as long as you follow the convention when building the layout graph, there shouldn’t be any problems.
--
Dr. Miro Spönemann
Software Engineer

Telefon: +49 (0)431 99026 870
Mobil:   +49 (0)151 426 794 59
itemis AG
Niederlassung Kiel
Am Germaniahafen 1
24143 Kiel

Rechtlicher Hinweis:
Sitz der Gesellschaft: Lünen
Amtsgericht: Dortmund HRB 20621, USt-IdNr. DE 23 11 77 498
Vorstand: Jens Wagener (Vorsitzender), Wolfgang Neuhaus, Sebastian Neus, Dr. Georg Pietrek, Jens Trompeter
Aufsichtsrat: Prof. Dr. Burkhard Igel (Vors.), Michael Neuhaus, Jennifer Fiorentino

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail

Back to the top