| Hallo Christoph,
yes, maybe we should open a bugzilla to discuss the details... 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.
That will be realizable in either case, by either creating KVectors directly from the simple double values or by means of a simple conversion library between GEF4 Geometry and 'KGeometry' (we already provide these kind of conversion support for SWT, AWT, and JavaFX).
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.
That sounds reasonable. Do you need to listen to changes of individual values like x, y, width, height, or would it be sufficient to listen for changes of 'position', 'size', etc.? The second one will probably also be provided when using GEF4 Geometry, while the first case is not supported there (GEF4 Geometry does not provide any change listener mechanism yet; and I am not sure if it should).
In either case, if we decide against GEF4 Geometry, I think I would also opt to directly use primitives (doubles) instead of introducing new abstractions like KPoint.
- 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.
I understand. Actually I forgot to include the KLabeledGraphElement; I did not want to do away with it.
I would then propose to eliminate the KEdgeLayout interface (as already discussed) and to rename the KShapeLayout-interface into KShape. That way, the used terminology should be consistent.
- 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.
Up to now that has been provided via the property/attribute mechanism. With Zest.FX we have started to use CSS classes/ids/styles to specify the rendering. These are provided via the property/attribute mechanism (potentially augmented by an external CSS stylesheet).
- 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
Cheers Alexander
--
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
_______________________________________________
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
-- Dr. Alexander Nyßen Dipl.-Inform. Software-Engineer Telefon: +49 (0) 231 / 98 60-202 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
|
