20 Mar
2012
20 Mar
'12
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