1 Mar
2012
1 Mar
'12
9:02 a.m.
Hi Dennis,
Could you describe what you do in relation to the
color?
When initializing the graph (in doInitialize: aGraph) I do the following:
...
graph removeAllNodes.
graph addNode: rootNode.
...
I remove all nodes and add only the root node.
To draw the treemap I use a recursive function, which starts at the rootNode and goes
through all "children" using the edge definitions. Then I layout (changing
position, shape, color, etc.) the children nodes of the current node and add them back to
the graph.
This is fun :). It goes against the original idea of Mondrian, but it is actually quite
intriguing as an idea: by affecting the graph, you are essentially making a layout a graph
transformation. This is quite nice.
However, I took a deeper look at the code and I see that you are adding the nodes back to
the same root. This is strange. I guess you want to simulate the zOrder. When I read your
above comments I thought that you are creating a nested graph. I mean instead of adding
the node back to the global graph, you could pass in the current node and add the children
to it. What do you think?
I'm now pretty sure it has something to do with
caching, because when I change colors and create the view anew, sometimes the old colors
are still used.
It's not a cache. The Shape object is a strategy shared among multiple Figures. So, if
you want to get multiple shapes, you need to instantiate new shapes.
But this behavior most probably stems from the fact
that the way I create this layout was not intended to be done like this.
Indeed, the Layout was never meant to change the shape of the node. But, we are
experimenting, so anything is possible :).
Since my layout inherits from MOAbstractGraphLayout I
will study this class and its implementors some more. But any pointers how to do things
more the Mondrian way would be appreciated.
As you noted, there should be no decision regarding interaction and color in the layout.
Ideally.
Ideally :). Perhaps you can add a separate option in the layout to override the existing
shape.
For now I will leave colors and interactions out of
the layout, I can add these outside of it, when creating the view itself to color leaf
nodes differently for example. (But would be interested to solve the coloring / caching
question nevertheless).
Furthermore, for the weight, you can use the size mapped on the nodes. Like this I can
define the weight as I want for each node, rather than treat all nodes in the same way.
This is important when we have nodes of different types that are introduced with multiple
nodes: statements.
Which size do you mean here? That of the shape of the node? Wouldn't that mean that I
give each node a size, take this as a weight, and change the size of the node again? Also,
sure there can be different kinds nodes, but I think one could deal with that in the
weight block itself.
I mean the height * width. If you have multiple kinds of nodes, you need ifs in the weight
block, but that is not nice. Again, it can be that if you do not specify the weight
explicitly, you get it from the node characteristics.
And a final thought for now: Another way to implement
a treemap is to actually implement it on top of Mondrian by constructing a nested graph
manually and assign the appropriate layout at each level. But, that is not ideal.
What I'm currently trying to do, what should be possible imho, is to render some
nodes in a certain way in Mondrian, with any layout, for example a gridLayout, but render
the single nodes as Treemaps. In this case, I think it's okay that a node renders all
of its children at once, because what I want in this case is a treemap of a single node,
and I think Mondrian should be able to just render that, without me having to manually
construct a nested graph.
See above.
I have two goals with this layout at the moment:
1. I think it would be cool to have it in Mondrian as generic as possible and done in
sync with all other layouts in terms of how to use it and how it works internally. But as
you said, it is an edge case, so it I think it will have to deviate in some aspects.
+10
2. My main goal is to port aspects of Softwarenaut to
Pharo. That means at the end I would like to have similar visualizations as Softwarenaut
provides in Pharo. The question will then just be how much will be in the layout itself
and how much outside.
+100
Cheers,
Doru
Thanks again for the feedback, looking forward to
discuss this some more :)
Cheers,
Doru
On 28 Feb 2012, at 16:02, Dennis Schenk wrote:
--
www.tudorgirba.com
"Beauty is where we see it."
Hi,
I'm working on a treemap layout in Mondrian. I created the basic functionality but am
far from finished.
For the current progress see the following screenshots:
http://cl.ly/342z261g021c3X1j3X2b - A visualization of a very simple java system
(https://github.com/mircealungu/SimpleSample)
http://cl.ly/3H3x1K1y3O3j430S0a2z - A visualization of FAMIX itself.
The following is an example of how one sets up the layout:
viewTreemapOn: view
view nodes: self nodes.
view edges: self nodes
from: [ :each | each ]
toAll: [ :each | each children ].
view layout: (MOTreeMapLayoutIncubation withWeightBlock: [ :e |
| model |
model := e model.
model isNil ifTrue: [
0.
]
ifFalse: [
e model entity numberOfLinesOfCode.
].
]).
The tree structure is given by the edges definition. The layout is created with a weight
block (lines of code here, but could be anything).
At the end I'd like to have something like:
http://cl.ly/3v1L3O2a2n1H1C2x3J0V - TreeMap in Softwarenaut in VisualWorks.
This is the first code that I'm writing with Mondrian, so I'm sure it could be
improved in many areas. If anyone sees a problem with how I set up the layout. please do
tell. If anyone wants to look at the code in detail please take a look at
MOTreeMapLayoutIncubation in my Softwarenaut repository (I'm creating the tree map
layout as part of the Softwarenaut port to Pharo):
MCHttpRepository
location: 'http://www.squeaksource.com/Softwarenaut'
user: ''
password: ''
The layout is currently in this repo, if it is more mature, it would be cool to add it to
Mondrian itself. I'd like to make it as generic as possible.
Now for some specific questions:
The red colors you see in the screenshots is actually a bug. What I would like to do is
only color the leaf nodes, but somehow (my guess is, it has something to do with shape
caching?), it also colors the containment blocks.
The way I do it is, while ging through the nodes (MONode) to draw them
If it is a leaf
node shape fillColor: ((Color fromString: '#ff0000') alpha: 0.1).
If it is a containment block:
node shape fillColor: (Color fromString: '#eeeeee').
But somehow all shapes (except the root node) are colored with the red translucent color.
Does anyone have an idea why this could be the case?
In general: I'm doing the styling of the nodes (also tried to add some interactivity)
directly inside the layout, but I'm not sure if this is the Mondrian way to do this,
since normally shape definitions and interaction is defined when creating the view. Is
this okay? Or should I do this in another way?
My thought was that I'd like to have a treemap layout with default, nice looking
interactions, colors etc. without having to define them outside, when defining the view,
so it needs as little setup as possible.
Any inputs in general are greatly appreciated.
Cheers,
Dennis
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
www.tudorgirba.com
"Live like you mean it."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev