Mondrian to Roassal: TreeMap
Locked
 
|
Hi all,
With the recent release of Roassal I thought I try it out and see if I can port my TreeMapLayout from Mondrian to the new engine. First of all: I really like Roassal. I felt while it was similar to 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.
There are two things which are missing (or I did not find them) to enable to draw a real TreeMap though: z-ordering and making edges invisible. Roassal seems to render the nodes in the order they are given to it, 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.
And how would I go on about making edges invisible? Cheers, Dennis
_______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
> With the recent release of Roassal I thought I try it out and see if I can port my TreeMapLayout from Mondrian to the new engine.
That would be excellent. > First of all: I really like Roassal. I felt while it was similar to 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. > There are two things which are missing (or I did not find them) to 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. > Roassal seems to render the nodes in the order they are given to it, 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 [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
Re: Mondrian to Roassal: TreeMap
|
|
On Tue, May 22, 2012 at 2:54 PM, Alexandre Bergel <[hidden email]> wrote:
That worked, thanks
How are the shapes actually drawn? What determines the order?
Why do you think zOrder would hamper quadtrees?
_______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
> The reason is the following: http://cl.ly/040v2X1w1V3g1o3m410A
> > How are the shapes actually drawn? What determines the order? > Why do you think zOrder would hamper quadtrees? 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 > > > Cheers, > Alexandre > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > 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 |
Re: Mondrian to Roassal: TreeMap
|
|
On Tue, May 22, 2012 at 4:45 PM, Alexandre Bergel
<[hidden email]> wrote: >> The reason is the following: http://cl.ly/040v2X1w1V3g1o3m410A >> >> How are the shapes actually drawn? What determines the order? > > >> Why do you think zOrder would hamper quadtrees? > > 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. 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. 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. Cheers, Doru > Cheers, > Alexandre > >> >> >> Cheers, >> Alexandre >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> 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 -- www.tudorgirba.com "Every thing has its own flow" _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
Re: Mondrian to Roassal: TreeMap
|
|
On Tue, May 22, 2012 at 5:06 PM, Tudor Girba <[hidden email]> 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?
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.
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, _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
Re: Mondrian to Roassal: TreeMap
|
|
I think that the Mondrian facade should be rethought in the context of Roassal. Treemaps are special cases in which a normal graph is transformed into a nested one. Both in Mondrian and in Roassal the facade provides direct access to the 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. Cheers, Doru Sent from my iPhone
_______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
In reply to this post by Tudor Girba-2
> 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. 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 [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
In reply to this post by Dennis Schenk
> 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?
As we discussed, the ROLayout>>doPost: should do the thing. > 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? Shapes drawing is triggered by ROElement>>drawOn: The element drawing is triggered by ROView>>drawOn: Cheers, Alexandre > > > 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 > > > > Cheers, > > Alexandre > > > >> > >> > >> Cheers, > >> Alexandre > >> > >> -- > >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > >> 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 > > > > -- > www.tudorgirba.com > > "Every thing has its own flow" > > _______________________________________________ > 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 Tudor Girba-2
> Both in Mondrian and in Roassal the facade provides direct access to the 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 [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
Re: Mondrian to Roassal: TreeMap
|
|
In reply to this post by abergel
Ok, one more time.
Take a look at the attached pictures produced with a code like: view nodes: #(1 2 3) forEach: [:each | view shape rectangle withText. view node: each *10]. view shape line color: Color blue; width: 3. view edgesFromAssociations: {10->30} In Mondrian, the edge goes below node 20, but above the parent nodes. In Roassal, it goes above node 20. zOrder is just a mechanism. What you do with it is something else. With Mondrian, we wanted to address people that have little knowledge about how to visualize, and we want to make the defaults as powerful as possible to help them create appealing visualizations. This is why we use a special zOrder (we did not publish on that, but we should have :)) that basically says that an edge is lower than the least nested linked nodes, but higher than its parents. This is very useful when you have a tone of edges. For example, it is because of this mechanism that the class blueprint is legible even for large classes. Cheers, Doru   On 23 May 2012, at 02:53, Alexandre Bergel wrote:
_______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
Re: Mondrian to Roassal: TreeMap
|
|
In reply to this post by abergel
On Wed, May 23, 2012 at 3:20 AM, Alexandre Bergel <[hidden email]> wrote:
That would be very nice indeed. That would solve many problems for the Treemap. I was just trying to make sure that when dragging the root node of the Treemap, the outermost one, all other get dragged as well. This, as I understand, only happens if the ROElements are nested. To achieve this right now, I would have to do something similar I did with the Mondrian version of the layout: change the structure manually, which I dont know if that is even possible.
How can we achieve Dorus proposal? Is there something I can do? Will you, Alexandre, have time to work on this?
_______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
Re: Mondrian to Roassal: TreeMap
|
|
In reply to this post by Tudor Girba-2
Hi,
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. Cheers, Doru On 23 May 2012, at 09:15, Tudor Girba wrote: > Ok, one more time. > > Take a look at the attached pictures produced with a code like: > view nodes: #(1 2 3) forEach: [:each | > view shape rectangle withText. > view node: each *10]. > view shape line color: Color blue; width: 3. > view edgesFromAssociations: {10->30} > > In Mondrian, the edge goes below node 20, but above the parent nodes. In Roassal, it goes above node 20. > > zOrder is just a mechanism. What you do with it is something else. With Mondrian, we wanted to address people that have little knowledge about how to visualize, and we want to make the defaults as powerful as possible to help them create appealing visualizations. > > This is why we use a special zOrder (we did not publish on that, but we should have :)) that basically says that an edge is lower than the least nested linked nodes, but higher than its parents. This is very useful when you have a tone of edges. For example, it is because of this mechanism that the class blueprint is legible even for large classes. > > Cheers, > Doru > > > <zOrder-roassal.png><zOrder-mondrian.png> > > On 23 May 2012, at 02:53, Alexandre Bergel wrote: > >>> 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. >> >> 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 >> [hidden email] >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > www.tudorgirba.com > > "Be rather willing to give than demanding to get." > > > -- www.tudorgirba.com "Speaking louder won't make the point worthier." _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
In reply to this post by Tudor Girba-2
This is a good case. From the discussion I had with Dennis, I added a way to sort the nodes. This is something I will push, to adress the situation you gave. I am absolutely for a mechanism to sort nodes, as a zOrder. But I want to have it without having a variable zOrder on the class ROElement. I really want to keep ROElement as light as possible. This is difficult, not only for Roassal, but in general: I do not know a root class of a GUI framework that is light. Cheers, Alexandre NB: I will be away for 4 days, without computer. I should answer emails, but no programming.
_______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
In reply to this post by Dennis Schenk
> How can we achieve Dorus proposal? Is there something I can do? Will you, Alexandre, have time to work on this? I really like this idea. Thanks Doru for sharing your experience and vision. It was not immediately apparent to me that layouting elements as a treemap implies to transform the structure of the graph from "connected" to "nested". I will give a try at this. Having a transformation facility should not be that difficult actually. I will try next week, once back from my short trip. Cheers, Alexandre _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
In reply to this post by Tudor Girba-2
> 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. Well, I exactly want to avoid having such a field. Maybe something like a mechanism of perspective for the collection of nodes. Alexandre _______________________________________________ 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 |