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@tudorgirba.com> wrote:
Hi,

On Tue, Mar 20, 2012 at 10:05 AM, Dennis Schenk
<d.schenk@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.

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@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@iam.unibe.ch
>> >>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>> >>>>
>> >>>> --
>> >>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
>> >>>> Alexandre Bergel  http://www.bergel.eu
>> >>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>> _______________________________________________
>> >>>> Moose-dev mailing list
>> >>>> Moose-dev@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@iam.unibe.ch
>> >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>> >>
>> >> --
>> >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
>> >> Alexandre Bergel  http://www.bergel.eu
>> >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>> >>
>> >>
>> >>
>> >>
>> >>
>> >> _______________________________________________
>> >> Moose-dev mailing list
>> >> Moose-dev@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@iam.unibe.ch
>> > https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>
>> --
>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
>> Alexandre Bergel  http://www.bergel.eu
>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>>
>>
>>
>>
>>
>> _______________________________________________
>> Moose-dev mailing list
>> Moose-dev@iam.unibe.ch
>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>
>
>
> _______________________________________________
> Moose-dev mailing list
> Moose-dev@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@iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

_______________________________________________
Moose-dev mailing list
Moose-dev@iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

-- 
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.