Re: [gef-dev] Graph Structure Proposal

[Ujhelyi Zoltán <ujhelyiz@xxxxxxxxxx>]

Hi,

also answering inline.

On 2014.07.08., at 17:43, Alexander Nyßen <alexander.nyssen@xxxxxxxxx> wrote:

> Hi Miro, 
> 
> let me reply to both your posts at once (I have copied your earlier post in here as well). My comments are inline...
> 
>> Hi all,
>> 
>> 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.
Yes, this is the part we are discussing in parallel threads right now. +1

>> 
>> 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 
> 
>> Am 08.07.2014 um 15:29 schrieb Miro Spoenemann <msp@xxxxxxxxxxxxxxxxxxxxxx>:
> 
>> Hi again,
>> 
>> I attached a class diagram giving an overview of our proposal.
>> A brief explanation:
>> 
>> * 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?).
> 
>> 
>> * Graph elements may have identifier strings, which is useful for
>> serialization, e.g. with Xtext.
>> 
>> * Nodes, edges, and ports may have labels.
>> 
>> * Nodes, ports, and labels are shapes with a position and a size.
>> 
>> * Edges have a start point at the source, an end point at the target,
>> and a possibly empty list of bend points in between.
>> 
>> * 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.

>> 
>> * Nodes may have children, which constitute a subgraph. A child node
>> may have multiple parents, as discussed in our recent telco. In most
>> cases this will be only one parent, but there are rare applications
>> where multiple parents may be useful.
> 
> This seems to be reasonable. @Zoltan, Matthias: does the use of the term "subgraph" here match the term "subgraph" in Zest, or would it rather match to a "nested graph" there?
This sounds really like nested graphs.

>> 
>> 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).

>> 
>> By the way, I created the class diagram with our "KLighD" visualization
>> framework and using automatic layout. The framework is quite similar to
>> what Zest does, see
>> http://rtsys.informatik.uni-kiel.de/~biblio/downloads/papers/acme12.pdf
> 
> Quite nice! :-).
Yeah, really nice.

Cheers,
Zoltán
-- Zoltán Ujhelyi
https://www.inf.mit.bme.hu/en/members/ujhelyiz

Fault Tolerant Systems Research Group
Budapest University of Technology and Economics