TreeMapLayout in Mondrian
Locked
 
|
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 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 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 [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
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 > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- www.tudorgirba.com "Live like you mean it." _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
Hi Doru,
Thanks for your feedback. Some thoughts inline in your mail:
On Tue, Feb 28, 2012 at 21:06, Tudor Girba <[hidden email]> wrote: Hi Dennis,
Thanks for this, added it as an example to the tests.
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).
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.
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 :)
_______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
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: > > > 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 > > [hidden email] > > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > www.tudorgirba.com > > "Live like you mean it." > > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- www.tudorgirba.com "Beauty is where we see it." _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
In reply to this post by Dennis Schenk
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 > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
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: > >> 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 >> [hidden email] >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- www.tudorgirba.com "Don't give to get. Just give." _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
>> 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. 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? 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 >>> [hidden email] >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> >> _______________________________________________ >> Moose-dev mailing list >> [hidden email] >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > www.tudorgirba.com > > "Don't give to get. Just give." > > > > > > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
Hi,
On 5 Mar 2012, at 20:44, Alexandre Bergel wrote: >>> 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. > > 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 > 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 >>>> [hidden email] >>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>> >>> -- >>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>> Alexandre Bergel http://www.bergel.eu >>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> [hidden email] >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> -- >> www.tudorgirba.com >> >> "Don't give to get. Just give." >> >> >> >> >> >> >> _______________________________________________ >> Moose-dev mailing list >> [hidden email] >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > _______________________________________________ > Moose-dev mailing list > [hidden email] > 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 [hidden email] 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 >>>>> [hidden email] >>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>> >>>> -- >>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>> Alexandre Bergel http://www.bergel.eu >>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Moose-dev mailing list >>>> [hidden email] >>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>> >>> -- >>> www.tudorgirba.com >>> >>> "Don't give to get. Just give." >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> [hidden email] >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> >> _______________________________________________ >> Moose-dev mailing list >> [hidden email] >> 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 > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
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
(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 <[hidden email]> wrote:
_______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
Hi,
On Tue, Mar 20, 2012 at 10:05 AM, Dennis Schenk <[hidden email]> 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 <[hidden email]> > 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 >> >>>>> [hidden email] >> >>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >>>> >> >>>> -- >> >>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> >>>> Alexandre Bergel http://www.bergel.eu >> >>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> _______________________________________________ >> >>>> Moose-dev mailing list >> >>>> [hidden email] >> >>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >>> >> >>> -- >> >>> www.tudorgirba.com >> >>> >> >>> "Don't give to get. Just give." >> >>> >> >>> >> >>> >> >>> >> >>> >> >>> >> >>> _______________________________________________ >> >>> Moose-dev mailing list >> >>> [hidden email] >> >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> >> >> -- >> >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> >> Alexandre Bergel http://www.bergel.eu >> >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> >> >> >> >> >> >> >> _______________________________________________ >> >> Moose-dev mailing list >> >> [hidden email] >> >> 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 >> > [hidden email] >> > https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> >> _______________________________________________ >> Moose-dev mailing list >> [hidden email] >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > -- www.tudorgirba.com "Every thing has its own flow" _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
On Tue, Mar 20, 2012 at 11:17, Tudor Girba <[hidden email]> wrote: Hi, Thanks for clearing that up.
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.
_______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
In reply to this post by Dennis Schenk
> 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 <[hidden email]> 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 > >>>>> [hidden email] > >>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > >>>> > >>>> -- > >>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > >>>> Alexandre Bergel http://www.bergel.eu > >>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> _______________________________________________ > >>>> Moose-dev mailing list > >>>> [hidden email] > >>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > >>> > >>> -- > >>> www.tudorgirba.com > >>> > >>> "Don't give to get. Just give." > >>> > >>> > >>> > >>> > >>> > >>> > >>> _______________________________________________ > >>> Moose-dev mailing list > >>> [hidden email] > >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > >> > >> -- > >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > >> Alexandre Bergel http://www.bergel.eu > >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > >> > >> > >> > >> > >> > >> _______________________________________________ > >> Moose-dev mailing list > >> [hidden email] > >> 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 > > [hidden email] > > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
In reply to this post by Dennis Schenk
Hi Dennis,
What is the status of the tree layout? Alexandre On 20 Mar 2012, at 08:16, Dennis Schenk wrote:
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
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 <[hidden email]> wrote:
_______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
«
Return to Moose
|
1 view|%1 views
| Free forum by Nabble | Edit this page |