| Re: [gef-dev] Graph Structure Proposal |
Hi Alexander, sorry to have brought up a few points that were already discussed -- it's getting a bit hard to follow the extensive mail conversations. ;) On 22/09/14 11:42, Alexander Nyßen wrote: >> - KShapeLayout doesn't use double fields anymore to specify the >> coordinates and the size, but Point and Dimension objects. While not >> using fields is not a problem in general, we should be using EMF objects >> that give us change notifications and are easily serializable. Our >> favourite solution would actually be to simply leave the double fields >> around, just to get away with less objects. Point and Dimention >> accessors could still be provided (getLocation(), getDimension(), and >> appropriate setters). > > As already mentioned, I thought that using the GEF4 Geometry classes > would be beneficial because layout algorithm implementations could > directly use the higher abstractions provided by the library. As > demonstrated by the KGraphCopier there is not a real impact in > serialization or copying when using them instead of own EClass > abstractions. Maybe we should take a detailed look at your usage of > these fields, so we can identify what your detailed requirements are. We > can then collect the pros and cons of both approaches and decide on a > solution (I do not resist on using the GEF4 Geometry classes if other > solutions are favorable). You convinced me on the serialization and copying points. That seems to be solved. I'm still not a big fan of using the geometry classes in the model for two reasons: 1. Most KIELER layout algorithms actually import the input KGraph into their own specialized graph structure designed for their particular requirements. During that process, the coordinates and dimension are usually converted into KVector objects, which we also have a rather extensive maths library for. We thus preferred to go for four double values instead of full-blown objects. Whatever solution we go for, it is quite probable that for the time being we will keep on using KVectors internally for the simple reason of avoiding the amount of work required for a switch. 2. More importantly, we modeled any coordinates (KPoint instances used in KEdgeLayout) as EMF objects to be able to listen to changes on the whole EMF model. If we are interested in changes to the coordinates of a node or the bend points of an edge, we can simply use built-in EMF mechanisms to listen for these changes instead of having to use a hybrid approach (listening for EMF changes and signing up for whatever change notification system non-objects plugged into the model tree are using). It is the second reason that makes it seem favourable to stay within the EMF realm here. >> - Speaking of KEdgeLayout, the interface could well be eliminated since >> only KEdge implements it. It would be perfectly fine though to leave it >> in to have a counterpart to KShapeLayout. Something to think about. > > As already said, I would prefer to eliminate the KEdgeLayout interface, > as it does not provide additional abstraction towards KEdge. With > respect to the "counterpart" argument, I would even go further and say > that KShapeLayout does not seem to be the right term to refer to the > common concept above KNode, KLabel, and KPort. For me, this would > actually be the KNode (as its the counterpart to the KEdge), and a > KGraph IMHO should consist of KNodes and KEdges (and not of KEdges and > KShapes). As KNode is already used, I would rather rename this to > something more appropriate, e.g. KShape, rather then having some kind of > 'Layout' abstraction. IMHO the hierarchy could be as follows: > > KGraphElement > > KNode | KEdge > > 'KShape' | KLabel | KPort > > What do you think? I think this would lead to confusion. The term "node" is quite clearly defined for graphs, and labels and ports are not nodes. Nodes, labels, and ports however do have the same basic shape, so in my view it makes perfect sense to derive all of them from KShape. Note that this does not imply that graphs are made up of edges and shapes. The inheritance tree is different from the references between the objects. A graph will always consist of nodes that may have further nodes as children. Each node may have ports and labels as well as outgoing edges. Another thing: your proposed inheritance tree does away with KLabeledGraphElement altogether which implies that labels can have labels themselves, which is currently not the case. I don't see why we shouldn't do it that way (even though KIELER probably wouldn't support labels of labels, at least not in the beginning), but I wanted to point out the difference. >> - Our rendering technology, KLighD, uses rendering information attached >> to KGraph elements. So far, they were attached as KGraphData objects to >> the different KGraph elements. We would like to add a "rendering" >> attribute to KGraphElement to provide a means for users to plug >> rendering information into the elements as they see fit. > > What is the need for some dedicated mechanism here. Wouldn't the generic > property mechanism be sufficient? Sure, we could always continue attaching rendering information as KGraphData objects. We just thought this might be a good time to talk about rendering as a first-class citizen in the graph structure. For us, it has become important enough to justify this. I don't know, however, how rendering is defined in Gef4 and if this would make sense in any way from your point of view. >> - In the original KGraph meta model, KShapeLayouts could have KInsets >> that were used to specify the insets of compound nodes. These are >> missing in the new proposal for some reason (perhaps Miro forgot about >> them as well in his proposal?), but must be added again. > > I think Miro changed that (and already said something about his changes). Yep, that's fine for me. Cheers, Christoph Daniel -- Christoph Daniel Schulze Christian-Albrechts University of Kiel Department of Computer Science Real-Time and Embedded Systems Group Room 1112 Phone +49 (0)431 880-7297 Olshausenstr. 40 24098 Kiel Germany
Attachment:
signature.asc
Description: OpenPGP digital signature