| [gef-dev] Graph Structure Proposal |
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. * 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. * 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. 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. 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 Regards Miro
Attachment:
graph.png
Description: PNG image
