Re: [gef-dev] Graph Structure Proposal

[Miro Spoenemann <msp@xxxxxxxxxxxxxxxxxxxxxx>]

Hi,
see below.

>>> in KIELER we have solved this problem using an extension point where
>>> * layout options, i.e. parameters of layout algorithms, can be declared
>>> with some meta data such as identifier, name, and data type;
>>> * layout algorithms can be declared together with a list of supported
>>> layout options.
>>
>> At least for Zest.FX, I would rather like to avoid using extension points (which might make a JavaFX standalone scenario more complex). Nevertheless, each layout algorithm should indeed provide this kind of information (that was what Matthias and I had in mind with the properties). Up to now, in GEF4 Layout this is rather implicit, which is bad.

In KIELER the extension point is used only for generic handling of
layout algorithms and their parameters, e.g. for the user interface. The
algorithms can also be invoked independently of these meta data.
In our current understanding, we would migrate only the graph data
structure to GEF, but not the rest of our infrastructure (extension
point, service classes, etc.).


>>> These meta data are gathered in a singleton service class. As a result,
>>> we could implement a generic "Layout" view, very similar to the
>>> "Properties" view, where a layout algorithm can be selected and the list
>>> of supported layout options is then updated automatically, so the user
>>> can access all parameters of the algorithm.
>>
>> I do not see the need for a singleton service yet. Nevertheless, it would be nice to provide these kind of parametrization options also via the UI (in Zest.FX.UI). While a distinct "layout" view could be an option, one could also think of integrating such kind of things directly into the properties view.
>>
> This is the point where the internal logic of Kieler and Zest was different. If I understood correctly, Kieler reads the graph, and based on the properties it tries to select the "optimal" layout algorithm from a selected pool. On the other hand, Zest was relying on single layouts, which were useful for including model-dependent 

No, we don't have an automatic selection of an "optimal" layout
algorithm (there has been some research on this, but it is not part of
the official release). We rather use default values as a basis, which
can be overridden in particular applications with another extension
point. For instance, you can use the extension point to specify that
your particular diagram editor A shall be handled with layout algorithm
X. Whenever you open an editor instance of A and click on the layout
button, algorithm X is selected based on this preconfiguration.
We also have other ways to configure the layout, e.g. with an API for
programmatic access to the layout algorithms and their parameters.
More details in our Wiki:
http://rtsys.informatik.uni-kiel.de/confluence/x/0IF1


>>> * All graph elements are property holders. Properties have generic
>>> types, which is very useful to avoid massive type casting of property
>>> values. This concept is compatible with the layout options registered
>>> via the extension point mentioned in my previous mail.
>>
>> That's very similar to what Matthias and I had in mind with the properties. Seems to be a reasonable approach, while (as mentioned above) the need for an extension point is not yet clear to me for relating the options to an algorithm (an algorithm could also directly expose this kind of information in its interface, right?).

The properties used in the data structure can be used independently of
the extension point. So we have two levels of information: the full set
of meta data in the extension point (for generic handling, mainly for
the UI) and a reduced set encoded as instances of IProperty (for direct
programmatic access).


>>> * Edges may have a source port and a target port, but that is optional.
>>
>> From the experience you have gained so far, is the port concept the right abstraction, or would it rather be useful to generalize it into something like an "overlapping" of nodes?
> In my opinion, ports are different than overlapping nodes - they are similar to anchor points, but they are visible. There are very specific rules about positioning these ports; most of them do no apply to subnodes/overlapping nodes. But maybe Miro has a different use case.

Ports are necessary whenever the anchor points of edges are constrained
to certain positions. For instance, in electric circuit schematics or
similar diagrams this is crucial to get a good layout.
A considerable amount of research in our group has been spent on the
topic of layout algorithms supporting such port constraints.


>>> Regarding the question whether to use EMF or not, we decided that we
>>> (read: the KIELER project) need EMF in any case. We have two options:
>>> * specify the data structure directly in Ecore, or
>>> * create interfaces and an EMF-independent implementation in one plugin
>>> and an Ecore-based implementation in another plugin.
>>> Even if EMF is used, it is possible to use the data structure in
>>> Eclipse-independent applications by shipping the plugins
>>> org.eclipse.emf.common and org.eclipse.emf.ecore with it. This gives an
>>> overhead of about 1.6 MB.
>>
>> I do not object to using EMF and I think that the overhead is something that we could well live with. Actually the approach you describe would facilitate the split of GEF4 Graph into interfaces and implementation, as I proposed earlier. I think from our viewpoint, the following would be desirable:
>>
>> 1) the generated interfaces should not make use of the EMF collection classes (i.e. use a plain List instead of an EList) and (if possible) should not extend EObject, so we could put them into a bundle without any EMF dependencies (I think this can be achieved by certain EMF genmodel options).
>> 2) the implementation classes could be put into a separate bundle that depends on EMF. I do not think we would have to provide a non-EMF-based implementation in addition, at least I do not see a direct use case for this yet.
>>
>> This way, the use case of writing adapters between GEF4 Graph interfaces and a custom model would remain pretty much lightweight (no EMF contracts to follow), while a transformation scenario would also be best supported (here, EMF seems to be advantageous). 
> It is possible to remove all EMF classes from the interface. The only thing required is having some javadoc tags defined for the interface, after that EMF can generate everything required. I have first-hand experience with this - if we can follow the (naming) conventions of EMF, it works really well. The most problematic point I see is providing a modifiable list for multivalued attributes - this requires specific list implementations that can send change notifications (at least if we want to make the graph model dynamic).

Would it be feasible that I send a proposal consisting of an Ecore model
file, and you generate EMF-free interfaces + EMF-bound implementation
out of it?

Miro