Hi Doru,

Thanks for your feedback. Some thoughts inline in your mail:

On Tue, Feb 28, 2012 at 21:06, Tudor Girba <tudor@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@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@iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev