28 Feb
2012
28 Feb
'12
4:02 p.m.
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
28 Feb
28 Feb
9:06 p.m.
Hi Dennis,
Thanks for doing this.
When we get to the treemap we get to the edge of Mondrian. That is because a treemap is
best presented as a nested graph. However, in Mondrian there is no distinction between the
conceptual graph and the presentation one. They are the same. This means that when you
take a flat graph and represent it as a tree map, you only simulate the nesting.
I took a quick look at the example. Here is a short example that does not depend on a
model:
view nodes: (1 to: 1000).
view edgesFrom: [ :each | each // 10 ].
view layout: (MOTreeMapLayoutIncubation withWeightBlock: [ :e | e model ]).
Could you describe what you do in relation to the color?
As you noted, there should be no decision regarding interaction and color in the layout.
Ideally.
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.
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.
Cheers,
Doru
On 28 Feb 2012, at 16:02, Dennis Schenk wrote:
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."
29 Feb
29 Feb
3:37 p.m.
Hi Doru,
Thanks for your feedback. Some thoughts inline in your mail:
On Tue, Feb 28, 2012 at 21:06, Tudor Girba <tudor(a)tudorgirba.com> wrote:
Hi Dennis,
Thanks for doing this.
When we get to the treemap we get to the edge of Mondrian. That is because
a treemap is best presented as a nested graph. However, in Mondrian there
is no distinction between the conceptual graph and the presentation one.
They are the same. This means that when you take a flat graph and represent
it as a tree map, you only simulate the nesting.
I took a quick look at the example. Here is a short
example that does not
depend on a model:
view nodes: (1 to: 1000).
view edgesFrom: [ :each | each // 10 ].
view layout: (MOTreeMapLayoutIncubation withWeightBlock: [ :e | e model ]).
Thanks for this, added it as an example to the tests.
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.
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.
But this behavior most probably stems from the fact that the way I create
this layout was not intended to be done like this.
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.
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.
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.
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.
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.
Thanks again for the feedback, looking forward to discuss this some more :)
Cheers,
Doru
On 28 Feb 2012, at 16:02, Dennis Schenk wrote:
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
1 Mar
1 Mar
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 
2 Mar
2 Mar
1:02 p.m.
Hi Dennis,
I briefly had a look at your layout.
Why not to wrap the nodes into a new class MOTreeMapNode.
Like this, you will not have to change the shape of the node.
You could also have two different TreeMap: one that use the edges to do the nesting, and
another that use the nesting.
There is no problem to include your layout in Mondrian once it is stable and properly
tested.
I will probably use your layout for Roassal, a visualization engine I am working on.
Alexandre
On 28 Feb 2012, at 12:02, Dennis Schenk wrote:
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
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
3 Mar
3 Mar
10:23 p.m.
Hi,
On 2 Mar 2012, at 13:02, Alexandre Bergel wrote:
Hi Dennis,
I briefly had a look at your layout.
Why not to wrap the nodes into a new class MOTreeMapNode.
Like this, you will not have to change the shape of the node.
I do not see what this would achieve.
Cheers,
Doru
You could also have two different TreeMap: one that
use the edges to do the nesting, and another that use the nesting.
There is no problem to include your layout in Mondrian once it is stable and properly
tested.
I will probably use your layout for Roassal, a visualization engine I am working on.
Alexandre
On 28 Feb 2012, at 12:02, Dennis Schenk wrote:
--
www.tudorgirba.com
"Don't give to get. Just give."
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
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
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
5 Mar
5 Mar
8:44 p.m.
I briefly had
a look at your layout.
Why not to wrap the nodes into a new class MOTreeMapNode.
Like this, you will not have to change the shape of the node.
I do not see what this would achieve. You could also have two different TreeMap: one
that use the edges to do the nesting, and another that use the nesting.
There is no problem to include your layout in Mondrian once it is stable and properly
tested.
I will probably use your layout for Roassal, a visualization engine I am working on.
Alexandre
On 28 Feb 2012, at 12:02, Dennis Schenk wrote:
--
www.tudorgirba.com
"Don't give to get. Just give."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev 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
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
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
6 Mar
6 Mar
8:29 a.m.
Hi,
On 5 Mar 2012, at 20:44, Alexandre Bergel wrote:
How can you have different size for each node? Using your example:
view nodes: (1 to: 1000).
view edgesFrom: [ :each | each // 10 ].
view layout: (MOTreeMapLayoutIncubation withWeightBlock: [ :e | e model ]).
All the nodes have the same shape, which in this case, the very same size.
In the treemap, not all the nodes have the same shape. How do you achieve this without
wrapping?
The sharing of the shape is just a convenience. But, you can provide a shape instance for
each node :)
Cheers,
Doru
I briefly had a look at your layout.
Why not to wrap the nodes into a new class MOTreeMapNode.
Like this, you will not have to change the shape of the node.
I do not see what this would achieve. 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
"In a world where everything is moving ever faster,
one might have better chances to win by moving slower."
You could also have two different TreeMap: one
that use the edges to do the nesting, and another that use the nesting.
There is no problem to include your layout in Mondrian once it is stable and properly
tested.
I will probably use your layout for Roassal, a visualization engine I am working on.
Alexandre
On 28 Feb 2012, at 12:02, Dennis Schenk wrote:
--
www.tudorgirba.com
"Don't give to get. Just give."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev 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
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
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
9:33 p.m.
All the nodes
have the same shape, which in this case, the very same size.
In the treemap, not all the nodes have the same shape. How do you achieve this without
wrapping?
The sharing of the shape is just a convenience. But, you can provide a shape instance for
each node :) > view nodes: (1 to: 1000).
Then there will be one shape for all the nodes.
No wrapping implies copying the shape for each node, and changing the height: and width:
This is not difficult to do however.
Alexandre
Cheers,
Doru
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
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
"In a world where everything is moving ever faster,
one might have better chances to win by moving slower."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev You could also have two different TreeMap: one
that use the edges to do the nesting, and another that use the nesting.
There is no problem to include your layout in Mondrian once it is stable and properly
tested.
I will probably use your layout for Roassal, a visualization engine I am working on.
Alexandre
On 28 Feb 2012, at 12:02, Dennis Schenk wrote:
> 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
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
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
"Don't give to get. Just give."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
20 Mar
20 Mar
10:05 a.m.
Hi,
Just a quick update on the status of the TreeMapLayout for Mondrian.
Two Screenshots to start:
http://cl.ly/1V2t2k06001m0P0B3r1M - example little java application
http://cl.ly/3D202C2l2b0V1A2y0G2y - Famix
(weights are lines of code)
The yellow highlighting is added outside of the layout itself.
The performance is not really good at the moment, notable in the famix
example, where there are many nodes. I solved the coloring problem by
adding new copies of shapes to all the nodes as suggested (*node
adoptNewShape: node shape copy*), but I guess this needs a lot of memory.
By the way: How was it possible that before this, there was only one shape
for all the nodes, for which I could change the size and position for all
of the nodes, but I could not have independent coloring for each node?
I will look into all your suggestions (thanks!) some more and try to
refactor more aspects.
I am still a bit confused about the use of MOShapes and rectangles.
Currently I am doing the follow to draw a node in the treemap:
*node setBoundsTo: rectangle*. Which uses a rectangle that has a fixed
position and height and width. But I run into problems when using
rectangles with fixed positions when doing the following:
I'm trying to use the treemap as a sub-layout, meaning that one could use
any layout, for example a gridLayout, as the main layout, but every node is
displayed as a treemap. Because this, fixed positions would need to be
relative to a single nodes "inner coordinative system", but they are
relative to the canvas.
I'm also having some troubles to set the sizes of the nodes. I guess the
right way to do this would be to set the sizes for all the nodes in the
grid layout where the view is described, right? If so, the disadvantage is,
that they can't be based on the weight of a treemap compared to others.
Also I'm asking myself a conceptual question at the moment: should the
TreeMapLayout expect the given nodes to always have exactly one root node?
Or should it be able to generate a virtual root node, when there are more
than one root node? At first I implemented the latter. But the problem with
that was that the virtual root node did not have a model specified, because
there was none. But I need a single, outermost container which holds the
whole treeMap together, or don't I?
Dorus example:
view := MOViewRenderer new.
view nodes: (1 to: 1000).
view edgesFrom: [ :each | each // 10 ].
view layout: (MOTreeMapLayoutIncubation withWeightBlock: [ :e | e model ]).
view open.
has 10 root Nodes, and does not work anymore at the moment because of that.
Any opinions on how to handle that?
I will keep you updated with my progress.
Thanks and cheers,
Dennis
On Tue, Mar 6, 2012 at 21:33, Alexandre Bergel <alexandre.bergel(a)me.com>wrote;wrote:
--
www.tudorgirba.com
"In a world where everything is moving ever faster,
one might have better chances to win by moving slower."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
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
> All the
nodes have the same shape, which in this case, the very same
size.
> In the treemap, not all the nodes have the
same shape. How do you
achieve this without wrapping?
The sharing of the shape is just a convenience. But, you can provide a
shape
instance for each node :)
Okay, but if you write:
> view nodes: (1 to: 1000).
Then there will be one shape for all the nodes.
No wrapping implies copying the shape for each node, and changing the
height: and width:
This is not difficult to do however.
Alexandre
Cheers,
Doru
> Cheers,
> Alexandre
>
>>
>>> You could also have two different TreeMap: one that use the edges to
do the nesting, and another that use the nesting.
>>>
>>> There is no problem to include your layout in Mondrian once it is
stable and properly tested.
>>>
>>> I will probably use your layout for Roassal, a visualization engine I
am working on.
>>>
>>> Alexandre
>>>
>>>
>>> On 28 Feb 2012, at 12:02, Dennis Schenk wrote:
>>>
>>>> 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
>
> --
> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> 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
"Don't give to get. Just give."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
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
11:17 a.m.
Hi,
On Tue, Mar 20, 2012 at 10:05 AM, Dennis Schenk
<d.schenk(a)students.unibe.ch> wrote:
Hi,
Just a quick update on the status of the TreeMapLayout for Mondrian.
Two Screenshots to start:
http://cl.ly/1V2t2k06001m0P0B3r1M - example little java application
http://cl.ly/3D202C2l2b0V1A2y0G2y - Famix
(weights are lines of code)
Excellent!
The yellow highlighting is added outside of the layout
itself.
The performance is not really good at the moment, notable in the famix
example, where there are many nodes. I solved the coloring problem by adding
new copies of shapes to all the nodes as suggested (node adoptNewShape: node
shape copy), but I guess this needs a lot of memory.
By the way: How was it possible that before this, there was only one shape
for all the nodes, for which I could change the size and position for all of
the nodes, but I could not have independent coloring for each node?
The Shape is a transformation that is applied *at rendering time* by
executing the blocks with the model behind the figure as input. For
example, when we say:
view shape rectangle width: [:number | number * 10 ]
view nodes: #(1 2 3)
The block will be executed for every node at rendering time, and based
on the model behind the node (which is a number in this case), you
will have nodes of different widths.
I will look into all your suggestions (thanks!) some
more and try to
refactor more aspects.
I am still a bit confused about the use of MOShapes and rectangles.
Currently I am doing the follow to draw a node in the treemap:
node setBoundsTo: rectangle. Which uses a rectangle that has a fixed
position and height and width. But I run into problems when using rectangles
with fixed positions when doing the following:
I'm trying to use the treemap as a sub-layout, meaning that one could use
any layout, for example a gridLayout, as the main layout, but every node is
displayed as a treemap. Because this, fixed positions would need to be
relative to a single nodes "inner coordinative system", but they are
relative to the canvas.
Bounds are relative and not absolute in Mondrian. To get the absolute
bounds, you have to ask explicitly for absoluteBounds.
In any case, you should use translateTo: and not setBoundsTo:. Look at
the other layouts.
I'm also having some troubles to set the sizes of
the nodes. I guess the
right way to do this would be to set the sizes for all the nodes in the grid
layout where the view is described, right? If so, the disadvantage is, that
they can't be based on the weight of a treemap compared to others.
I do not understand this part. Could you please re-explain?
Also I'm asking myself a conceptual question at
the moment: should the
TreeMapLayout expect the given nodes to always have exactly one root node?
Or should it be able to generate a virtual root node, when there are more
than one root node? At first I implemented the latter. But the problem with
that was that the virtual root node did not have a model specified, because
there was none. But I need a single, outermost container which holds the
whole treeMap together, or don't I?
Well, the RootNode is also a node that does not have a model (this is
the root node on which you build your graphs). This does not prevent
us from using it :). Either add a default model, or have your own
subclass of MONode.
Cheers,
Doru
Dorus example:
view := MOViewRenderer new.
view nodes: (1 to: 1000).
view edgesFrom: [ :each | each // 10 ].
view layout: (MOTreeMapLayoutIncubation withWeightBlock: [ :e | e model ]).
view open.
has 10 root Nodes, and does not work anymore at the moment because of that.
Any opinions on how to handle that?
I will keep you updated with my progress.
Thanks and cheers,
Dennis
On Tue, Mar 6, 2012 at 21:33, Alexandre Bergel <alexandre.bergel(a)me.com>
wrote:
Okay, but if you write:
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
www.tudorgirba.com
"Every thing has its own flow"
All the
nodes have the same shape, which in this case, the very same
size.
In the treemap, not all the nodes have the same shape. How do you
achieve this without wrapping?
The sharing of the shape is just a convenience. But, you can provide a
shape instance for each node :) > view nodes: (1 to: 1000).
Then there will be one shape for all the nodes.
No wrapping implies copying the shape for each node, and changing the
height: and width:
This is not difficult to do however.
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 Cheers,
Alexandre
>
>> You could also have two different TreeMap: one that use the edges to
>> do the nesting, and another that use the nesting.
>>
>> There is no problem to include your layout in Mondrian once it is
>> stable and properly tested.
>>
>> I will probably use your layout for Roassal, a visualization engine I
>> am working on.
>>
>> Alexandre
>>
>>
>> On 28 Feb 2012, at 12:02, Dennis Schenk wrote:
>>
>>> 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
>>
>> --
>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
>> 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
>
> "Don't give to get. Just give."
>
>
>
>
>
>
> _______________________________________________
> Moose-dev mailing list
> Moose-dev(a)iam.unibe.ch
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
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
"In a world where everything is moving ever faster,
one might have better chances to win by moving slower."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
1:16 p.m.
On Tue, Mar 20, 2012 at 11:17, Tudor Girba <tudor(a)tudorgirba.com> wrote:
What I am doing at the moment is the following:
*layout: nodes rectangle: rectangle level: level*
*
*
This is the main (recursive) method that I am using to create the layout.
nodes is a collection of nodes to draw inside the bounds of the given
rectangle.
rectangle is an instance of the Graphics-Primitive class Rectangle. So it
has an origin and a corner. They are absolute related to the canvas of a
Mondrian Renderer (At least I think they are, else my method should not
have worked so far).
And like I said, I used *node setBoundsTo: rectangle* to draw a single node.
Using translateTo sounds good, but how will I tell the node its width and
height (I have to do this, since I am doing a treemap layout with nodes of
different sizes. As far as I can tell, all the other layouts are not
concerned with node bounds, since they expect these to be defined outside
of the layout. Is this correct?
Any thoughts on how to solve this elegantly?
I think if we can discuss the question above, this will resolve itself.
Will look into this again, thanks.
Hi,
On Tue, Mar 20, 2012 at 10:05 AM, Dennis Schenk
<d.schenk(a)students.unibe.ch> wrote:
Thanks for clearing that up.
Hi,
Just a quick update on the status of the TreeMapLayout for Mondrian.
Two Screenshots to start:
http://cl.ly/1V2t2k06001m0P0B3r1M - example little java application
http://cl.ly/3D202C2l2b0V1A2y0G2y - Famix
(weights are lines of code)
Excellent!
The yellow highlighting is added outside of the
layout itself.
The performance is not really good at the moment, notable in the famix
example, where there are many nodes. I solved the coloring problem by
adding
new copies of shapes to all the nodes as
suggested (node adoptNewShape:
node
shape copy), but I guess this needs a lot of
memory.
By the way: How was it possible that before this, there was only one
shape
for all the nodes, for which I could change the
size and position for
all of
the nodes, but I could not have independent
coloring for each node?
The Shape is a transformation that is applied *at rendering time* by
executing the blocks with the model behind the figure as input. For
example, when we say:
view shape rectangle width: [:number | number * 10 ]
view nodes: #(1 2 3)
The block will be executed for every node at rendering time, and based
on the model behind the node (which is a number in this case), you
will have nodes of different widths.
I will look into all your suggestions (thanks!)
some more and try to
refactor more aspects.
I am still a bit confused about the use of MOShapes and rectangles.
Currently I am doing the follow to draw a node in the treemap:
node setBoundsTo: rectangle. Which uses a rectangle that has a fixed
position and height and width. But I run into problems when using
rectangles
with fixed positions when doing the following:
I'm trying to use the treemap as a sub-layout, meaning that one could use
any layout, for example a gridLayout, as the main layout, but every node
is
displayed as a treemap. Because this, fixed
positions would need to be
relative to a single nodes "inner coordinative system", but they are
relative to the canvas.
Bounds are relative and not absolute in Mondrian. To get the absolute
bounds, you have to ask explicitly for absoluteBounds.
In any case, you should use translateTo: and not setBoundsTo:. Look at
the other layouts.
I'm also having some troubles to set the
sizes of the nodes. I guess the
right way to do this would be to set the sizes for all the nodes in the
grid
layout where the view is described, right? If so,
the disadvantage is,
that
they can't be based on the weight of a
treemap compared to others.
I do not understand this part. Could you please re-explain?
Also I'm asking myself a conceptual question
at the moment: should the
TreeMapLayout expect the given nodes to always have exactly one root
node?
Or should it be able to generate a virtual root
node, when there are more
than one root node? At first I implemented the latter. But the problem
with
that was that the virtual root node did not have
a model specified,
because
there was none. But I need a single, outermost
container which holds the
whole treeMap together, or don't I?
Well, the RootNode is also a node that does not have a model (this is
the root node on which you build your graphs). This does not prevent
us from using it :). Either add a default model, or have your own
subclass of MONode.
Cheers,
Doru
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
www.tudorgirba.com
"Every thing has its own flow"
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Dorus example:
view := MOViewRenderer new.
view nodes: (1 to: 1000).
view edgesFrom: [ :each | each // 10 ].
view layout: (MOTreeMapLayoutIncubation withWeightBlock: [ :e | e model
]).
view open.
has 10 root Nodes, and does not work anymore at the moment because of
that.
Any opinions on how to handle that?
I will keep you updated with my progress.
Thanks and cheers,
Dennis
On Tue, Mar 6, 2012 at 21:33, Alexandre Bergel <alexandre.bergel(a)me.com>
wrote:
>
> >> All the nodes have the same shape, which in this case, the very same
> >> size.
> >> In the treemap, not all the nodes have the same shape. How do you
> >> achieve this without wrapping?
> >
> > The sharing of the shape is just a convenience. But, you can provide a
> > shape instance for each node :)
>
> Okay, but if you write:
> >> view nodes: (1 to: 1000).
>
> Then there will be one shape for all the nodes.
> No wrapping implies copying the shape for each node, and changing the
> height: and width:
> This is not difficult to do however.
>
> Alexandre
>
>
>
> >
> > Cheers,
> > Doru
> >
> >
> >> Cheers,
> >> Alexandre
> >>
> >>>
> >>>> You could also have two different TreeMap: one that use the edges
to
> >>>> do the nesting, and another
that use the nesting.
> >>>>
> >>>> There is no problem to include your layout in Mondrian once it is
> >>>> stable and properly tested.
> >>>>
> >>>> I will probably use your layout for Roassal, a visualization
engine I
> >>>> am working on.
> >>>>
> >>>> Alexandre
> >>>>
> >>>>
> >>>> On 28 Feb 2012, at 12:02, Dennis Schenk wrote:
> >>>>
> >>>>> 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
>>>
>>> --
>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
>>> 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
>>
>> "Don't give to get. Just give."
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> Moose-dev mailing list
>> Moose-dev(a)iam.unibe.ch
>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>
> --
> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> 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
"In a world where everything is moving ever faster,
one might have better chances to win by moving slower."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
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
28 Mar
28 Mar
4:11 a.m.
Hi Dennis,
What is the status of the tree layout?
Alexandre
On 20 Mar 2012, at 08:16, Dennis Schenk wrote:
On Tue, Mar 20, 2012 at 11:17, Tudor Girba <tudor(a)tudorgirba.com> wrote:
Hi,
On Tue, Mar 20, 2012 at 10:05 AM, Dennis Schenk
<d.schenk(a)students.unibe.ch> wrote:
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Hi,
Just a quick update on the status of the TreeMapLayout for Mondrian.
Two Screenshots to start:
http://cl.ly/1V2t2k06001m0P0B3r1M - example little java application
http://cl.ly/3D202C2l2b0V1A2y0G2y - Famix
(weights are lines of code)
Excellent!
The yellow highlighting is added outside of the
layout itself.
The performance is not really good at the moment, notable in the famix
example, where there are many nodes. I solved the coloring problem by adding
new copies of shapes to all the nodes as suggested (node adoptNewShape: node
shape copy), but I guess this needs a lot of memory.
By the way: How was it possible that before this, there was only one shape
for all the nodes, for which I could change the size and position for all of
the nodes, but I could not have independent coloring for each node?
The Shape is a transformation that is applied *at rendering time* by
executing the blocks with the model behind the figure as input. For
example, when we say:
view shape rectangle width: [:number | number * 10 ]
view nodes: #(1 2 3)
The block will be executed for every node at rendering time, and based
on the model behind the node (which is a number in this case), you
will have nodes of different widths.
Thanks for clearing that up.
I will look into all your suggestions (thanks!)
some more and try to
refactor more aspects.
I am still a bit confused about the use of MOShapes and rectangles.
Currently I am doing the follow to draw a node in the treemap:
node setBoundsTo: rectangle. Which uses a rectangle that has a fixed
position and height and width. But I run into problems when using rectangles
with fixed positions when doing the following:
I'm trying to use the treemap as a sub-layout, meaning that one could use
any layout, for example a gridLayout, as the main layout, but every node is
displayed as a treemap. Because this, fixed positions would need to be
relative to a single nodes "inner coordinative system", but they are
relative to the canvas.
Bounds are relative and not absolute in Mondrian. To get the absolute
bounds, you have to ask explicitly for absoluteBounds.
In any case, you should use translateTo: and not setBoundsTo:. Look at
the other layouts.
What I am doing at the moment is the following:
layout: nodes rectangle: rectangle level: level
This is the main (recursive) method that I am using to create the layout.
nodes is a collection of nodes to draw inside the bounds of the given rectangle.
rectangle is an instance of the Graphics-Primitive class Rectangle. So it has an origin
and a corner. They are absolute related to the canvas of a Mondrian Renderer (At least I
think they are, else my method should not have worked so far).
And like I said, I used node setBoundsTo: rectangle to draw a single node.
Using translateTo sounds good, but how will I tell the node its width and height (I have
to do this, since I am doing a treemap layout with nodes of different sizes. As far as I
can tell, all the other layouts are not concerned with node bounds, since they expect
these to be defined outside of the layout. Is this correct?
Any thoughts on how to solve this elegantly?
I'm also having some troubles to set the
sizes of the nodes. I guess the
right way to do this would be to set the sizes for all the nodes in the grid
layout where the view is described, right? If so, the disadvantage is, that
they can't be based on the weight of a treemap compared to others.
I do not understand this part. Could you please re-explain?
I think if we can discuss the question above, this will resolve itself.
Also I'm asking myself a conceptual question
at the moment: should the
TreeMapLayout expect the given nodes to always have exactly one root node?
Or should it be able to generate a virtual root node, when there are more
than one root node? At first I implemented the latter. But the problem with
that was that the virtual root node did not have a model specified, because
there was none. But I need a single, outermost container which holds the
whole treeMap together, or don't I?
Well, the RootNode is also a node that does not have a model (this is
the root node on which you build your graphs). This does not prevent
us from using it :). Either add a default model, or have your own
subclass of MONode.
Will look into this again, thanks.
Cheers,
Doru
Dorus example:
view := MOViewRenderer new.
view nodes: (1 to: 1000).
view edgesFrom: [ :each | each // 10 ].
view layout: (MOTreeMapLayoutIncubation withWeightBlock: [ :e | e model ]).
view open.
has 10 root Nodes, and does not work anymore at the moment because of that.
Any opinions on how to handle that?
I will keep you updated with my progress.
Thanks and cheers,
Dennis
On Tue, Mar 6, 2012 at 21:33, Alexandre Bergel <alexandre.bergel(a)me.com>
wrote:
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
www.tudorgirba.com
"Every thing has its own flow"
_______________________________________________
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 > All the nodes have the same shape, which in
this case, the very same
> size.
> In the treemap, not all the nodes have the same shape. How do you
> achieve this without wrapping?
The sharing of the shape is just a convenience. But, you can provide a
shape instance for each node :)
Okay, but if you write:
> view nodes: (1 to: 1000).
Then there will be one shape for all the nodes.
No wrapping implies copying the shape for each node, and changing the
height: and width:
This is not difficult to do however.
Alexandre
Cheers,
Doru
> Cheers,
> Alexandre
>
>>
>>> You could also have two different TreeMap: one that use the edges to
>>> do the nesting, and another that use the nesting.
>>>
>>> There is no problem to include your layout in Mondrian once it is
>>> stable and properly tested.
>>>
>>> I will probably use your layout for Roassal, a visualization engine I
>>> am working on.
>>>
>>> Alexandre
>>>
>>>
>>> On 28 Feb 2012, at 12:02, Dennis Schenk wrote:
>>>
>>>> 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
>>>
>>> --
>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
>>> 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
>>
>> "Don't give to get. Just give."
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> Moose-dev mailing list
>> Moose-dev(a)iam.unibe.ch
>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>
> --
> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> 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
"In a world where everything is moving ever faster,
one might have better chances to win by moving slower."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
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
2:53 p.m.
Hi Alexandre,
I'm currently working on making the layout more versatile and trying to get
it to work more the "mondrian-way", i.e. at the moment im trying to use
some arbitrary layout, like a circle layout, as outer layout, wherein every
node is displayed as a treemap. To get this to work correctly I have to
refactor my layout code.
I hope to have it finished in one or two weeks (am able to work on it two
days per weeks).
On Wed, Mar 28, 2012 at 04:11, Alexandre Bergel <alexandre.bergel(a)me.com>wrote;wrote:
Hi Dennis,
What is the status of the tree layout?
Alexandre
On 20 Mar 2012, at 08:16, Dennis Schenk wrote:
On Tue, Mar 20, 2012 at 11:17, Tudor Girba <tudor(a)tudorgirba.com> wrote:
What I am doing at the moment is the following:
*layout: nodes rectangle: rectangle level: level*
*
*
This is the main (recursive) method that I am using to create the layout.
nodes is a collection of nodes to draw inside the bounds of the given
rectangle.
rectangle is an instance of the Graphics-Primitive class Rectangle. So it
has an origin and a corner. They are absolute related to the canvas of a
Mondrian Renderer (At least I think they are, else my method should not
have worked so far).
And like I said, I used *node setBoundsTo: rectangle* to draw a single
node.
Using translateTo sounds good, but how will I tell the node its width and
height (I have to do this, since I am doing a treemap layout with nodes of
different sizes. As far as I can tell, all the other layouts are not
concerned with node bounds, since they expect these to be defined outside
of the layout. Is this correct?
Any thoughts on how to solve this elegantly?
I think if we can discuss the question above, this will resolve itself.
Will look into this again, thanks.
Hi,
On Tue, Mar 20, 2012 at 10:05 AM, Dennis Schenk
<d.schenk(a)students.unibe.ch> wrote:
Thanks for clearing that up.
Hi,
Just a quick update on the status of the TreeMapLayout for Mondrian.
Two Screenshots to start:
http://cl.ly/1V2t2k06001m0P0B3r1M - example little java application
http://cl.ly/3D202C2l2b0V1A2y0G2y - Famix
(weights are lines of code)
Excellent!
The yellow highlighting is added outside of the
layout itself.
The performance is not really good at the moment, notable in the famix
example, where there are many nodes. I solved the coloring problem by
adding
new copies of shapes to all the nodes as
suggested (node adoptNewShape:
node
shape copy), but I guess this needs a lot of
memory.
By the way: How was it possible that before this, there was only one
shape
for all the nodes, for which I could change the
size and position for
all of
the nodes, but I could not have independent
coloring for each node?
The Shape is a transformation that is applied *at rendering time* by
executing the blocks with the model behind the figure as input. For
example, when we say:
view shape rectangle width: [:number | number * 10 ]
view nodes: #(1 2 3)
The block will be executed for every node at rendering time, and based
on the model behind the node (which is a number in this case), you
will have nodes of different widths.
I will look into all your suggestions (thanks!)
some more and try to
refactor more aspects.
I am still a bit confused about the use of MOShapes and rectangles.
Currently I am doing the follow to draw a node in the treemap:
node setBoundsTo: rectangle. Which uses a rectangle that has a fixed
position and height and width. But I run into problems when using
rectangles
with fixed positions when doing the following:
I'm trying to use the treemap as a sub-layout, meaning that one could
use
any layout, for example a gridLayout, as the main
layout, but every
node is
displayed as a treemap. Because this, fixed
positions would need to be
relative to a single nodes "inner coordinative system", but they are
relative to the canvas.
Bounds are relative and not absolute in Mondrian. To get the absolute
bounds, you have to ask explicitly for absoluteBounds.
In any case, you should use translateTo: and not setBoundsTo:. Look at
the other layouts.
I'm also having some troubles to set the
sizes of the nodes. I guess the
right way to do this would be to set the sizes for all the nodes in the
grid
layout where the view is described, right? If so,
the disadvantage is,
that
they can't be based on the weight of a
treemap compared to others.
I do not understand this part. Could you please re-explain?
Also I'm asking myself a conceptual question
at the moment: should the
TreeMapLayout expect the given nodes to always have exactly one root
node?
Or should it be able to generate a virtual root
node, when there are
more
than one root node? At first I implemented the
latter. But the problem
with
that was that the virtual root node did not have
a model specified,
because
there was none. But I need a single, outermost
container which holds the
whole treeMap together, or don't I?
Well, the RootNode is also a node that does not have a model (this is
the root node on which you build your graphs). This does not prevent
us from using it :). Either add a default model, or have your own
subclass of MONode.
Cheers,
Doru
--
www.tudorgirba.com
"Every thing has its own flow"
_______________________________________________
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
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
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
Dorus example:
view := MOViewRenderer new.
view nodes: (1 to: 1000).
view edgesFrom: [ :each | each // 10 ].
view layout: (MOTreeMapLayoutIncubation withWeightBlock: [ :e | e model
]).
view open.
has 10 root Nodes, and does not work anymore at the moment because of
that.
Any opinions on how to handle that?
I will keep you updated with my progress.
Thanks and cheers,
Dennis
On Tue, Mar 6, 2012 at 21:33, Alexandre Bergel <alexandre.bergel(a)me.com
wrote:
>
> >> All the nodes have the same shape, which in this case, the very same
> >> size.
> >> In the treemap, not all the nodes have the same shape. How do you
> >> achieve this without wrapping?
> >
> > The sharing of the shape is just a convenience. But, you can provide
a
> > shape instance for each node :)
>
> Okay, but if you write:
> >> view nodes: (1 to: 1000).
>
> Then there will be one shape for all the nodes.
> No wrapping implies copying the shape for each node, and changing the
> height: and width:
> This is not difficult to do however.
>
> Alexandre
>
>
>
> >
> > Cheers,
> > Doru
> >
> >
> >> Cheers,
> >> Alexandre
> >>
> >>>
> >>>> You could also have two different TreeMap: one that use the edges
to
> >>>> do the nesting, and another
that use the nesting.
> >>>>
> >>>> There is no problem to include your layout in Mondrian once it is
> >>>> stable and properly tested.
> >>>>
> >>>> I will probably use your layout for Roassal, a visualization
engine I
> >>>> am working on.
> >>>>
> >>>> Alexandre
> >>>>
> >>>>
> >>>> On 28 Feb 2012, at 12:02, Dennis Schenk wrote:
> >>>>
> >>>>> 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
>>>>
>>>> --
>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
>>>> 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
>>>
>>> "Don't give to get. Just give."
>>>
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Moose-dev mailing list
>>> Moose-dev(a)iam.unibe.ch
>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>
>> --
>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
>> 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
>
> "In a world where everything is moving ever faster,
> one might have better chances to win by moving slower."
>
>
>
>
> _______________________________________________
> Moose-dev mailing list
> Moose-dev(a)iam.unibe.ch
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
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
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
21 Mar
21 Mar
5:42 a.m.
Just a quick update on the status of the TreeMapLayout
for Mondrian.
Two Screenshots to start:
http://cl.ly/1V2t2k06001m0P0B3r1M - example little java application
http://cl.ly/3D202C2l2b0V1A2y0G2y - Famix
(weights are lines of code)
The yellow highlighting is added outside of the layout itself.
This is really cool.
The performance is not really good at the moment,
notable in the famix example, where there are many nodes. I solved the coloring problem by
adding new copies of shapes to all the nodes as suggested (node adoptNewShape: node shape
copy), but I guess this needs a lot of memory.
Yes, this is the way to do I think. I do not think that it will use that much memory. A
shape is not that fat after all.
By the way: How was it possible that before this,
there was only one shape for all the nodes, for which I could change the size and position
for all of the nodes, but I could not have independent coloring for each node?
As Doru said, the color is computed against the model. However, when you want to
indivisually change the shape without changing the model, ... well.... copying the shape
as you did is the easiest way.
I will look into all your suggestions (thanks!) some
more and try to refactor more aspects.
I am still a bit confused about the use of MOShapes and rectangles. Currently I am doing
the follow to draw a node in the treemap:
node setBoundsTo: rectangle. Which uses a rectangle that has a fixed position and height
and width. But I run into problems when using rectangles with fixed positions when doing
the following:
setBoundsTo: is not the way to go. If you need to resize a node, then copy the shape.
Also I'm asking myself a conceptual question at
the moment: should the TreeMapLayout expect the given nodes to always have exactly one
root node? Or should it be able to generate a virtual root node, when there are more than
one root node? At first I implemented the latter. But the problem with that was that the
virtual root node did not have a model specified, because there was none. But I need a
single, outermost container which holds the whole treeMap together, or don't I?
There should be only one root in the visualization. Why not to put your treemap within a
node?
view node: 'your treemap' forIt: [
view nodes: (1 to: 1000).
view edgesFrom: [ :each | each // 10 ].
view layout: (MOTreeMapLayoutIncubation withWeightBlock: [ :e | e model ]).
].
Alexandre
Dorus example:
view := MOViewRenderer new.
view nodes: (1 to: 1000).
view edgesFrom: [ :each | each // 10 ].
view layout: (MOTreeMapLayoutIncubation withWeightBlock: [ :e | e model ]).
view open.
has 10 root Nodes, and does not work anymore at the moment because of that.
Any opinions on how to handle that?
I will keep you updated with my progress.
Thanks and cheers,
Dennis
On Tue, Mar 6, 2012 at 21:33, Alexandre Bergel <alexandre.bergel(a)me.com> wrote:
Okay, but if you write:
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
All the
nodes have the same shape, which in this case, the very same size.
In the treemap, not all the nodes have the same shape. How do you achieve this without
wrapping?
The sharing of the shape is just a convenience. But, you can provide a shape instance for
each node :) > view nodes: (1 to: 1000).
Then there will be one shape for all the nodes.
No wrapping implies copying the shape for each node, and changing the height: and width:
This is not difficult to do however.
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
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev Cheers,
Alexandre
--
www.tudorgirba.com
"In a world where everything is moving ever faster,
one might have better chances to win by moving slower."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
> You could also have two different TreeMap: one that use the edges to do the nesting,
and another that use the nesting.
>
> There is no problem to include your layout in Mondrian once it is stable and properly
tested.
>
> I will probably use your layout for Roassal, a visualization engine I am working on.
>
> Alexandre
>
>
> On 28 Feb 2012, at 12:02, Dennis Schenk wrote:
>
>> 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
>
> --
> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> 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
"Don't give to get. Just give."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
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
4410
days inactive
4439
days old
14 comments
3 participants
participants (3)
-
Alexandre Bergel -
Dennis Schenk -
Tudor Girba