Community
Participate
Working Groups
As recently announced on the gef-dev mailing list, the KIELER group is planning to contribute their layout algorithm implementations as part of a new Eclipse project. As the result of some initial discussions on how both projects could collaborate, the following points have been agreed on so far: 1) The GEF4 Graph model and the KGraph model should be merged to a unified Graph model, which should then be used as the basis for Zest visualization, for KIELER (and Zest) layout algorithms, as well as for the DOT-Im/Export. 2) The unified Graph model should be split into a set of EMF-independent interfaces (i.e. no dependencies to EObject, EList, EMap, etc.) and related EMF-based default implementations. Miro Spönemann has created an EMF-based graph structure (which contains all concepts required form the KIELER side) as a starting point for a more detailed discussion: http://github.com/franchi82/kgraph. We should evolve this so that it could be contributed as a replacement for GEF4 Graph as outlined above.
(In reply to Alexander Nyssen from the gef-dev mailing list) >- What exactly was the motivation of factoring our EdgeLayout into own interface? Does it make sense to haven an Edge without the properties contained therein? > - What was the motivation of doing the same for ShapeLayout? It seems all GraphElements extend also this interface. Why is there then no "Shape" abstraction but only a ShapeLayout? ShapeLayout and EdgeLayout specify the layout of graph elements: ShapeLayout for nodes, ports, and labels, and EdgeLayout for edges. The graph elements implement these interfaces, so the attributes are always available. The motivation for ShapeLayout is to avoid duplicating the same attributes for the three implementing classes. The EdgeLayout is not necessary in this sense, but is made for consistency. Of course it would also be possible to store all concrete layout information (e.g. xpos, ypos, width, height) as properties of the corresponding graph elements, but I think it is a good idea to make them first class citizens, since they are accessed very often in layout algorithms and other related code. >- Why exactly do we need the PropertyMapping? It seems transient properties are already handled by a map. Why not use the same mechanism here? What is the notion of "persisting" them? With the IPropertyHolder interface (a plain Java interface), properties are mapped to Object, which cannot be handled by EMF w.r.t. serializing and parsing. Therefore a list of PropertyMapping instances can be held in addition to the transient IProperty -> Object map. A PropertyMapping maps String -> String, so it can be created using toString(). Parsing such a mapping, however, requires the meta data of the properties to be known, e.g. through extension point contributions. As long as the data structure is only used in memory, the PropertyMappings can be ignored. I know the solution is not completely satisfying, but it is a compromise to allow both EMF-based serialization and simple programmatic access of properties. I would like to rethink the problem for a while, so probably I can come up with a better solution.
(In reply to Miro Spoenemann from comment #1) > (In reply to Alexander Nyssen from the gef-dev mailing list) > >- What exactly was the motivation of factoring our EdgeLayout into own interface? Does it make sense to haven an Edge without the properties contained therein? > > - What was the motivation of doing the same for ShapeLayout? It seems all GraphElements extend also this interface. Why is there then no "Shape" abstraction but only a ShapeLayout? > > ShapeLayout and EdgeLayout specify the layout of graph elements: ShapeLayout > for nodes, ports, and labels, and EdgeLayout for edges. The graph elements > implement these interfaces, so the attributes are always available. The > motivation for ShapeLayout is to avoid duplicating the same attributes for > the three implementing classes. The EdgeLayout is not necessary in this > sense, but is made for consistency. > > Of course it would also be possible to store all concrete layout information > (e.g. xpos, ypos, width, height) as properties of the corresponding graph > elements, but I think it is a good idea to make them first class citizens, > since they are accessed very often in layout algorithms and other related > code. > Then I would propose to rather create an abstraction that corresponds to a "shape", i.e. a common concept for nodes, ports, and labels (technically speaking just a renaming of ShapeLayout to something reasonable; while I somehow don't like "Shape" here) and to integrate the EdgeLayout attributes simply into the Edge. > > >- Why exactly do we need the PropertyMapping? It seems transient properties are already handled by a map. Why not use the same mechanism here? What is the notion of "persisting" them? > > With the IPropertyHolder interface (a plain Java interface), properties are > mapped to Object, which cannot be handled by EMF w.r.t. serializing and > parsing. Therefore a list of PropertyMapping instances can be held in > addition to the transient IProperty -> Object map. A PropertyMapping maps > String -> String, so it can be created using toString(). Parsing such a > mapping, however, requires the meta data of the properties to be known, e.g. > through extension point contributions. > > As long as the data structure is only used in memory, the PropertyMappings > can be ignored. I know the solution is not completely satisfying, but it is > a compromise to allow both EMF-based serialization and simple programmatic > access of properties. > > I would like to rethink the problem for a while, so probably I can come up > with a better solution. We have implemented the concept of an IAdaptable within GEF4 MVC, which allows to register arbitrary adapters in a type-safe manner (under a class key). We have also built in support for injecting such kind of adapters polymorphically via some Guice extensions. I am currently generalizing the IAdaptable concept, so that adapters can be registered under a class key and a role qualifier in combination (bug #440145). I will further extend the functionality of the related Guice binding mechanism to support scopes (bug #439859), and finally plan to extract everything into an own independent bundle, so it can not only be used by those depending on MVC (bug #439933). I think this generalized IAdaptable concept could also be used for what is needed here w.r.t. properties (if not we could extend it). Maybe should take a look at it after I have completed the work outlined above. Would be nice if different GEF4 modules did not introduce very similar but different mechanisms for the same conceptual problem.
Maybe this helps to clarify what I meant in the last paragraph: having the notion introduced in bug #440145, a Property could be a specific AdapterKey.
(In reply to Alexander Nyssen from comment #2) > Then I would propose to rather create an abstraction that corresponds to a > "shape", i.e. a common concept for nodes, ports, and labels (technically > speaking just a renaming of ShapeLayout to something reasonable; while I > somehow don't like "Shape" here) and to integrate the EdgeLayout attributes > simply into the Edge. That's fine. > > With the IPropertyHolder interface (a plain Java interface), properties are > > mapped to Object, which cannot be handled by EMF w.r.t. serializing and > > parsing. Therefore a list of PropertyMapping instances can be held in > > addition to the transient IProperty -> Object map. A PropertyMapping maps > > String -> String, so it can be created using toString(). Parsing such a > > mapping, however, requires the meta data of the properties to be known, e.g. > > through extension point contributions. > > > > As long as the data structure is only used in memory, the PropertyMappings > > can be ignored. I know the solution is not completely satisfying, but it is > > a compromise to allow both EMF-based serialization and simple programmatic > > access of properties. > > > > I would like to rethink the problem for a while, so probably I can come up > > with a better solution. > > We have implemented the concept of an IAdaptable within GEF4 MVC, which > allows to register arbitrary adapters in a type-safe manner (under a class > key). We have also built in support for injecting such kind of adapters > polymorphically via some Guice extensions. > > I am currently generalizing the IAdaptable concept, so that adapters can be > registered under a class key and a role qualifier in combination (bug > #440145). I will further extend the functionality of the related Guice > binding mechanism to support scopes (bug #439859), and finally plan to > extract everything into an own independent bundle, so it can not only be > used by those depending on MVC (bug #439933). > > I think this generalized IAdaptable concept could also be used for what is > needed here w.r.t. properties (if not we could extend it). Maybe should take > a look at it after I have completed the work outlined above. Would be nice > if different GEF4 modules did not introduce very similar but different > mechanisms for the same conceptual problem. The properties mechanism in my current proposal enables type-safe and null-safe access to values stored with string identifiers. We have been using this concept in KIELER for four years, and it has proven very useful. Since most layout options use primitive types, storing their values with classes as it is done in IAdaptable does not work. However, maybe we could include both concepts in the data structure: We already have a "data" reference for graph elements meant for including objects that shall be referenced by their class. This could be adapted to IAdaptable. Regarding the problem with PropertyMappings, I propose to remove that class and the persistentProperties reference from this meta model. In order to serialize and parse the properties, we could create a separate meta model as part of KIELER and attach this to the graph elements with the "data" reference.
(In reply to Alexander Nyssen from comment #3) > Maybe this helps to clarify what I meant in the last paragraph: having the > notion introduced in bug #440145, a Property could be a specific AdapterKey. Ok, that could work. So graph elements could be both IAdaptable and IPropertyHolder, and a Property is an AdapterKey with an identifier but without a class reference? I don't know whether it's too confusing to have both concepts in the data structure, but certainly it would be very useful in order to support all the different use cases.
(In reply to Miro Spoenemann from comment #5) > Ok, that could work. So graph elements could be both IAdaptable and > IPropertyHolder, and a Property is an AdapterKey with an identifier but > without a class reference? I don't know whether it's too confusing to have > both concepts in the data structure, but certainly it would be very useful > in order to support all the different use cases. So, how should people know when to access properties through IPropertyHolder and when to use them through the adapter mechanism? This seems to me to be quite confusing.
(In reply to Christoph Schulze from comment #6) > (In reply to Miro Spoenemann from comment #5) > > Ok, that could work. So graph elements could be both IAdaptable and > > IPropertyHolder, and a Property is an AdapterKey with an identifier but > > without a class reference? I don't know whether it's too confusing to have > > both concepts in the data structure, but certainly it would be very useful > > in order to support all the different use cases. > > So, how should people know when to access properties through IPropertyHolder > and when to use them through the adapter mechanism? This seems to me to be > quite confusing. I think that was a misunderstanding. I was actually thinking of the IAdaptable mechanism (in the extended form) to be a potential replacement for the IPropertyHolder mechanism. Maybe let's come back to this after I have resolved bug #440145.
Changed the title from "Align GEF4 Graph with KGraph" to "Align GEF4 Layout with KGraph" because that - in contrast to what we initially planned - seems to be the more straightforward approach. The situation is as follows: 1) GEF4 Graph is the visualization model (and the target/source for DOT import/export) used by GEF4 Zest, i.e. GEF4 Zest visualizes a Graph-based model with predefined figures (which will have to be extended to provide something comparable to GraphViz visualization). 2) GEF4 Layout (i.e. the interfaces defined in GEF4 Layout and the local implementation provided by GEF4 Zest) is the layout model used by GEF4 Zest. That is, the GEF4 Graph-based content model is transferred into a GEF4 Layout-based model (which is passed as input to the layout algorithms), and the results are transferred back to GEF4 Graph-based contents model (and then visualized). As such, it makes more sense to align the GEF4 layout interfaces with KGraph (rather than the GEF4 Graph model). As a next step, we will thus try to revise the GEF4 layout interfaces so that they provide concepts compatible to the KGraph abstractions.
Removing the ISubgraphLayout (see bug #469472) is one of the tasks that should be performed here.
As agreed on with Christoph-Daniel Schulze (ELK), we will re-investigate this as soon as the ELK (Eclipse Layout Kernel) project has been properly created.
*** Bug 482932 has been marked as a duplicate of this bug. ***
(In reply to Alexander Nyßen from comment #10) > As agreed on with Christoph-Daniel Schulze (ELK), we will re-investigate > this as soon as the ELK (Eclipse Layout Kernel) project has been properly > created. Hi, do you have updates on your plans, ELK being an Eclipse project? Or do you wait until they get out of incubation? Thanks!
(In reply to Remi Schnekenburger from comment #12) > Hi, do you have updates on your plans, ELK being an Eclipse project? Or do > you wait until they get out of incubation? > Thanks! Cheers from the ELK project. We are currently in the process of working on our central graph data structure. We are targeting a 0.2.0 release for the end of the year, and I propose to talk about this ticket again once the release is out.
Thanks for this fast feedback, Christoph!
I just spoke with Alexander about how to proceed here. We agreed that we should implement a layout algorithm (according to the GEF4 Layout component) that transforms a GEF4 graph into an ElkGraph and applies an ELK layout algorithm. That would make all ELK algorithms available in Zest views and possibly also MVC editors, and would be independent of the ELK UI. Furthermore we should have a layout connector (according to the ELK infrastructure) that does the same graph transformation for Zest views, so they can participate in the ELK services and thus also the Layout view and the ELK layout action. I could create an initial contribution for this. I could start as soon as the new ElkGraph is finalized.
I created https://github.com/eclipse/elk/issues/86 for implementing this in ELK.
The joys of being at the same conference together. ;) Sounds like a good plan to me. If I remember correctly, GEF4 has its own connection to Graphviz, as does ELK. Once this ticket is done, it might be interesting to look at the two and perhaps unify them.
