2 Apr
2011
2 Apr
'11
7:55 p.m.
Hi,
On 2 Apr 2011, at 20:33, Alexandre Bergel wrote:
bounds is about the size of the shape. Is it reasonable to have a graph element answering
to the message #bounds?
Yes. Bounds is about the bounds of the figure. A Shape object is a strategy and it is
shared among multiple elements. Thus, it cannot hold data specific to one element.
I believe the below issues really stem from what we understand by Element.
As I said, in the very original version of Mondrian, we had Figure and Graph separately.
The Figure was responsible for the position and size. The Graph was a container.
Afterwards, we merged the two structures to have less objects and to have less indirection
which kind of made the code harder to follow.
So, Graph was merged in, and in the end we only had Figures. The idea of Mondrian was to
focus on the presentation, so Figure is really what it says: a Figure :). And like a
figure, it has a position and a size, and it knows how to draw itself on a physical
canvas, and how to deal with interaction. That is quite well defined.
Now, you renamed Figure to Element, which as I said from the beginning does not really
convey the original idea. And because of this name, now we can start to say that the job
of the Figure is not part of the responsibilities of an Element. While this could be a
possible direction, it goes away from the original idea.
I am just wary about adding more layers if there aren't strong reasons for it. On the
other hand, it can well be that it scales in the end. So, we can experiment but we should
be careful to trace the effects :)
sure
In addition, the layouting should not be at the level of GraphElement. It does not make
sense for an edge to do a layout.
In the original Mondrian, we actually could have graphs in the edges to model fancy
annotations on the edge. We had some experiments, but in the end we did not really manage
to get the bounds of the subgraph properly.
Sure (bis)
Yes. The node location should not be hosted within a node.
The location is the job of the node :). The caching structure might be somewhere else,
though.
MONode and MOEdge define displayOn:
A node needs the zordered-list to display its inner nodes.
I will move this into a visitor soon.
>> an edge:
>> - target and source node
But it is called by the graph element
Yes, I agree.
Updating the size of the root if you drag and drop a node. This could go in the Canvas
maybe.
As far as I remember, what was called a graph was an instance of the formally named
Figure (which was replaced by GraphElement).
Cheers,
Alexandre
Cheers,
Doru
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
www.tudorgirba.com
"To lead is not to demand things, it is to make them happen."
However, this has not been completely nice and clean.
For example, MOGraphElement defines #bounds, #absoluteBounds. MONode defines
#translatedBy:. Shall these methods be moved into the shape?
I disagree that this is a problem. The Element has a physical location and dimension, the
Shape is responsible for retrieving the actual values from the model. Currently, we have the following
responsibilities:
a graph element:
- keeping a ref to its shape
This is not a responsibility, it's a collaboration -
managing attributes
- managing nesting of nodes and edges
- layout
It is responsible for the positioning, but this is achieved through a collaboration
- supporting announcement
This is again a collaboration, because the interaction responsibility is handled by the
announcer. a node:
- keeping a location
- maintaining a zordered-list of elements to display
- dedicated caches (e.g., bitmap)
This is internal implementation, but it could probably be pushed externally somewhere.
- rendering on a canvas
Not quite correct. The actual rendering is taken care of by the shape. -
rendering on a canvas
Not quite correct. The actual rendering is taken care of by the shape. a root:
- selection box
I think this could go to the Canvas. - another
event management
I am not sure what this is. Clearly,
some responsibilities are ill located. I will do soon some cleaning...
I think there are some places for refactoring, but not that many as it might sound from
your mail. One thing that you might need to know is that we used to have an explicit Graph
entity. However, we ended up merging it in the Element because of scalability issues (less
objects). Perhaps the situation is different now, but we nevertheless should take care of
this aspect, too. Cheers,
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
www.tudorgirba.com
"Some battles are better lost than fought."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev