Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [gef-dev] Graph Structure Proposal

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.

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

> 
> Usually layout options are used as input of the algorithms. There are
> some rare cases where properties are used as output, e.g. to mark edges
> that have been routed with spline control points, but we don't
> distinguish explicitly between input and output properties. Whether a
> property is input or output is documented in the source code where the
> property constant is declared.
> 
> We'll present our proposal on the graph interface this afternoon or so.
> 
> Regards
>  Miro


> 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?

> 
> * 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?

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

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

> 
> Regards
>  Miro
> <graph.png>_______________________________________________
> gef-dev mailing list
> gef-dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe from this list, visit
> https://dev.eclipse.org/mailman/listinfo/gef-dev


Cheers
Alexander

--
Dr. Alexander Nyßen
Dipl.-Inform.
Software-Engineer

Telefon: +49 (0) 231 / 98 60-210
Telefax: +49 (0) 231 / 98 60-211
Mobil: +49 (0) 151 /  17396743

http://www.itemis.de 
alexander.nyssen@xxxxxxxxx 

itemis AG
Am Brambusch 15-24
44536 Lünen

Rechtlicher Hinweis:

Amtsgericht Dortmund, HRB 20621

Vorstand: Jens Wagener (Vors.), Wolfgang Neuhaus, Dr. Georg Pietrek, Jens Trompeter, Sebastian Neus

Aufsichtsrat: Dr. Burkhard Igel (Vors.), Stephan Grollmann, Michael Neuhaus


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


Back to the top