can port my TreeMapLayout from Mondrian to the new engine. That would be excellent. Mondrian it was easier to use and understand. I was able to throw away some boilerplate code in my layout, it is much cleaner now. Also, the porting did not took much time. Thanks. That is exactly the goal of Roassal. enable to draw a real TreeMap though: z-ordering and making edges invisible. Making edge invisible is easy. Just try: -=-=-=-=-=-=-=-=-=-=-=-= | view edges | view := ROMondrianViewBuilder new. view nodes: Collection withAllSubclasses. ( view edgesFrom: #superclass) do: [ :edge | edge - ROEdge ]. view treeLayout. view open -=-=-=-=-=-=-=-=-=-=-=-= You need to update to the last version. I also introduced an example and tests about making element invisible. The Mondrian builder assigns a shape per default. You can always remove it using Roassal facilities.

meaning the first node will be "under" all the others with the last one on top. Is there a way to alter this? In Mondrian every shape had a zOrder index. This is something that I do not have a solution yet. What exactly do you need? How do you want to specific the node ordering? The node ordering can certainly be changed, but I would like to do it without introducing a zOrder. The reason is that on some point, I would like to have quadtrees, and the zOrdering may hamper it.

Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. _______________________________________________ Moose-dev mailing list Moose-dev(a)iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

zOrder orders the elements to be drawn. Unfortunately, this order may be different from the one specified by a user. This zOrder is one of the reason that Mondrian was not as fast as Roassal. After some discussion with Doru, it is possible that I did not fully understand what are the properties of the zOrder. Actually, I am not completely sure whether zOrder would hamper quadtree, but it will certainly not simplify it. Let's try to find a easy way to solve your problem. Will it be enough for you to provide a sorting block to reorder the nodes? I can provide a easy way to do this.

Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel  http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. _______________________________________________ Moose-dev mailing list Moose-dev(a)iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

On Tue, May 22, 2012 at 5:06 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: On Tue, May 22, 2012 at 4:45 PM, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: My understanding of z-order is that its simply a height on the z-axis. The z-axis beeing the one which is perpendicular to the monitor surface :) That means a shape with higher z order is in front (and thus visible) of shapes with lower z order. You mean I could specify a sorting block and Roassal then draws the shapes in the resulting order? I'm not sure - when would I set this block and when would the sorting happen? I don't understand the inner workings of Roassel so good yet: Where exactly in the code are shapes drawn? At the moment, what makes a shape be in front (on the z-axis) of another? In the case of tree maps, it would be much better to construct nested nodes, rather than a flat graph. This would provide the nesting by default. I agree, but then we would have to change the inner workings of Roassal for this specific case? Or how would we go on about doing this? From my side - I have nested nodes in my model, I tell Roassal (or Mondrian) about the nesting via the edges. Regarding zOrder, its usefulness comes when it comes to drawing edges. Btw, zOrder does not have to be mandatory, but for it to work efficiently, you need to be able to store this as a property in the graph element. Yes, for layouting the TreeMap with Mondrian I added a zOrder setter to MONode, this way I had control over it (had the exact same problem, but it was solvable because MONode already had the zOrder property). Cheers, Doru -- www.tudorgirba.com "Every thing has its own flow" _______________________________________________ Moose-dev mailing list Moose-dev(a)iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev _______________________________________________ Moose-dev mailing list Moose-dev(a)iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

inner model. But, we could eliminate this restriction and have an intermediary model that the layout can transform into the rendered graph. Like this, the Treemap layout would transform the flat graph into a nested one and eliminate the edges altogether. +1

Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. _______________________________________________ Moose-dev mailing list Moose-dev(a)iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

You mean I could specify a sorting block and Roassal then draws the shapes in the resulting order? I'm not sure - when would I set this block and when would the sorting happen?

I don't understand the inner workings of Roassel so good yet: Where exactly in the code are shapes drawn? At the moment, what makes a shape be in front (on the z-axis) of another?

In the case of tree maps, it would be much better to construct nested nodes, rather than a flat graph. This would provide the nesting by default. I agree, but then we would have to change the inner workings of Roassal for this specific case? Or how would we go on about doing this? From my side - I have nested nodes in my model, I tell Roassal (or Mondrian) about the nesting via the edges. Regarding zOrder, its usefulness comes when it comes to drawing edges. Btw, zOrder does not have to be mandatory, but for it to work efficiently, you need to be able to store this as a property in the graph element. Yes, for layouting the TreeMap with Mondrian I added a zOrder setter to MONode, this way I had control over it (had the exact same problem, but it was solvable because MONode already had the zOrder property). Cheers, Doru -- www.tudorgirba.com "Every thing has its own flow" _______________________________________________ Moose-dev mailing list Moose-dev(a)iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev _______________________________________________ Moose-dev mailing list Moose-dev(a)iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

I have nothing against a zOrder. I am just trying to see what is exactly the use case for it. By the way, I did a skype with Dennis, apparently all the problems have been solved. Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. _______________________________________________ Moose-dev mailing list Moose-dev(a)iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

I forgot to mention that this zOder algorithm can be optional, but its efficiency depends on the ability of an element to actually have a zOrder field.