[Pharo-project] Fwd: [Moose-dev] Roassal new algorithms
Let's have this discussion in the Pharo list. Alexandre Begin forwarded message:
From: Alexandre Bergel <alexandre.bergel@me.com> Subject: [Moose-dev] Re: Roassal new algorithms Date: April 19, 2013 11:25:31 AM GMT-04:00 To: Moose-related development <moose-dev@iam.unibe.ch> Reply-To: Moose-related development <moose-dev@iam.unibe.ch>
There are more than simply linear, quadratic and cubic Bezier curves. In fact, as you can have as many control points as you wish, you can have a Bezier curve of any order.
Ok
But what I was calling RadialBezierCurve was a kind of strategy, I mean I have an abstract class which knows how to compute a curve, but I still have to choose my control points so I was thinking to create different subclasses whose role is to know what are their control points :
- The radial one choose its control points within the same radius as its source and its target.
Ah ok
I wanted to create an ortoVertical and an ortoHorizontal whose control points would have been computed differently, so that we could use Bezier curve for regular tree too.
It would be cool to have hierarchical bundles edges in Roassal. A screenshot of what it looks like:
The technical description: http://www.win.tue.nl/~dholten/papers/bundles_infovis.pdf
Alexandre
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
I've played with these before [1]. They work best with hierarchical names. In other words, in a flat namespace (say, showing class dependencies with just the class name) you end up with a very messy diagram. Let's assume you use "." as the name token separator. If you prefixed the names with their packages, say Tools-Debugger.Debugger, you'd get a better graph, where the bundles would be tighter. If you made things more hierarchical still, say with names like Tools.Debugger.Debugger, things would look even better. The deeper the naming hierarchy the fewer fat bundles you get in the image. frank [1] http://mbostock.github.io/d3/talk/20111116/bundle.html On 19 April 2013 16:37, Alexandre Bergel <alexandre.bergel@me.com> wrote:
Let's have this discussion in the Pharo list.
Alexandre
Begin forwarded message:
*From: *Alexandre Bergel <alexandre.bergel@me.com> *Subject: **[Moose-dev] Re: Roassal new algorithms* *Date: *April 19, 2013 11:25:31 AM GMT-04:00 *To: *Moose-related development <moose-dev@iam.unibe.ch> *Reply-To: *Moose-related development <moose-dev@iam.unibe.ch>
There are more than simply linear, quadratic and cubic Bezier curves. In fact, as you can have as many control points as you wish, you can have a Bezier curve of any order.
Ok
But what I was calling RadialBezierCurve was a kind of strategy, I mean I have an abstract class which knows how to compute a curve, but I still have to choose my control points so I was thinking to create different subclasses whose role is to know what are their control points :
- The radial one choose its control points within the same radius as its source and its target.
Ah ok
I wanted to create an ortoVertical and an ortoHorizontal whose control points would have been computed differently, so that we could use Bezier curve for regular tree too.
It would be cool to have hierarchical bundles edges in Roassal. A screenshot of what it looks like:
The technical description: http://www.win.tue.nl/~dholten/papers/bundles_infovis.pdf
Alexandre
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
This is a very cool visualization. There is no reason why we cannot do it in Pharo Alexandre On Apr 19, 2013, at 10:49 AM, Frank Shearar <frank.shearar@gmail.com> wrote:
I've played with these before [1]. They work best with hierarchical names. In other words, in a flat namespace (say, showing class dependencies with just the class name) you end up with a very messy diagram.
Let's assume you use "." as the name token separator. If you prefixed the names with their packages, say Tools-Debugger.Debugger, you'd get a better graph, where the bundles would be tighter. If you made things more hierarchical still, say with names like Tools.Debugger.Debugger, things would look even better.
The deeper the naming hierarchy the fewer fat bundles you get in the image.
frank
[1] http://mbostock.github.io/d3/talk/20111116/bundle.html
On 19 April 2013 16:37, Alexandre Bergel <alexandre.bergel@me.com> wrote: Let's have this discussion in the Pharo list.
Alexandre
Begin forwarded message:
From: Alexandre Bergel <alexandre.bergel@me.com> Subject: [Moose-dev] Re: Roassal new algorithms Date: April 19, 2013 11:25:31 AM GMT-04:00 To: Moose-related development <moose-dev@iam.unibe.ch> Reply-To: Moose-related development <moose-dev@iam.unibe.ch>
There are more than simply linear, quadratic and cubic Bezier curves. In fact, as you can have as many control points as you wish, you can have a Bezier curve of any order.
Ok
But what I was calling RadialBezierCurve was a kind of strategy, I mean I have an abstract class which knows how to compute a curve, but I still have to choose my control points so I was thinking to create different subclasses whose role is to know what are their control points :
- The radial one choose its control points within the same radius as its source and its target.
Ah ok
I wanted to create an ortoVertical and an ortoHorizontal whose control points would have been computed differently, so that we could use Bezier curve for regular tree too.
It would be cool to have hierarchical bundles edges in Roassal. A screenshot of what it looks like: <Screen Shot 2013-04-19 at 11.24.59 AM.png>
The technical description: http://www.win.tue.nl/~dholten/papers/bundles_infovis.pdf
Alexandre
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Oh absolutely! My comment comes from trying to analyse the dependencies between classes in my SIP stack [1]. What I found was that simply mapping dependencies in a flat namespace (as Delphi has) resulted in a tangled mess. Then I added the unit name to the classes, so I had, say, IdSipTransport.TIdSipTransport. That resulted in a slightly less tangled mess: the strands started to bundle together. Once I added a third layer - I grouped things into high level concepts like Transport, Transaction, Dialog, and so on - the strands bundled sufficiently tightly to actually be useful. I suspect the same will hold true for Pharo (and Squeak). So if you turn names like "Debugger class in the Tools-Debugger package" into Tools.Debugger.Debugger you'd be well on your way. frank [1] https://github.com/frankshearar/SipStack On 19 April 2013 19:57, Alexandre Bergel <alexandre.bergel@me.com> wrote:
This is a very cool visualization. There is no reason why we cannot do it in Pharo
Alexandre
On Apr 19, 2013, at 10:49 AM, Frank Shearar <frank.shearar@gmail.com> wrote:
I've played with these before [1]. They work best with hierarchical names. In other words, in a flat namespace (say, showing class dependencies with just the class name) you end up with a very messy diagram.
Let's assume you use "." as the name token separator. If you prefixed the names with their packages, say Tools-Debugger.Debugger, you'd get a better graph, where the bundles would be tighter. If you made things more hierarchical still, say with names like Tools.Debugger.Debugger, things would look even better.
The deeper the naming hierarchy the fewer fat bundles you get in the image.
frank
[1] http://mbostock.github.io/d3/talk/20111116/bundle.html
On 19 April 2013 16:37, Alexandre Bergel <alexandre.bergel@me.com> wrote: Let's have this discussion in the Pharo list.
Alexandre
Begin forwarded message:
From: Alexandre Bergel <alexandre.bergel@me.com> Subject: [Moose-dev] Re: Roassal new algorithms Date: April 19, 2013 11:25:31 AM GMT-04:00 To: Moose-related development <moose-dev@iam.unibe.ch> Reply-To: Moose-related development <moose-dev@iam.unibe.ch>
There are more than simply linear, quadratic and cubic Bezier curves. In fact, as you can have as many control points as you wish, you can have a Bezier curve of any order.
Ok
But what I was calling RadialBezierCurve was a kind of strategy, I mean I have an abstract class which knows how to compute a curve, but I still have to choose my control points so I was thinking to create different subclasses whose role is to know what are their control points :
- The radial one choose its control points within the same radius as its source and its target.
Ah ok
I wanted to create an ortoVertical and an ortoHorizontal whose control points would have been computed differently, so that we could use Bezier curve for regular tree too.
It would be cool to have hierarchical bundles edges in Roassal. A screenshot of what it looks like: <Screen Shot 2013-04-19 at 11.24.59 AM.png>
The technical description: http://www.win.tue.nl/~dholten/papers/bundles_infovis.pdf
Alexandre
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
On 19 April 2013 21:33, Frank Shearar <frank.shearar@gmail.com> wrote:
Oh absolutely!
My comment comes from trying to analyse the dependencies between classes in my SIP stack [1]. What I found was that simply mapping dependencies in a flat namespace (as Delphi has) resulted in a tangled mess.
Oh.. SIP. RTP/RTCP been there , did that :) implementing it in C++ years ago.
Then I added the unit name to the classes, so I had, say, IdSipTransport.TIdSipTransport. That resulted in a slightly less tangled mess: the strands started to bundle together.
Once I added a third layer - I grouped things into high level concepts like Transport, Transaction, Dialog, and so on - the strands bundled sufficiently tightly to actually be useful.
I suspect the same will hold true for Pharo (and Squeak). So if you turn names like "Debugger class in the Tools-Debugger package" into Tools.Debugger.Debugger you'd be well on your way.
frank
[1] https://github.com/frankshearar/SipStack
On 19 April 2013 19:57, Alexandre Bergel <alexandre.bergel@me.com> wrote:
This is a very cool visualization. There is no reason why we cannot do it in Pharo
Alexandre
On Apr 19, 2013, at 10:49 AM, Frank Shearar <frank.shearar@gmail.com> wrote:
I've played with these before [1]. They work best with hierarchical names. In other words, in a flat namespace (say, showing class dependencies with just the class name) you end up with a very messy diagram.
Let's assume you use "." as the name token separator. If you prefixed the names with their packages, say Tools-Debugger.Debugger, you'd get a better graph, where the bundles would be tighter. If you made things more hierarchical still, say with names like Tools.Debugger.Debugger, things would look even better.
The deeper the naming hierarchy the fewer fat bundles you get in the image.
frank
[1] http://mbostock.github.io/d3/talk/20111116/bundle.html
On 19 April 2013 16:37, Alexandre Bergel <alexandre.bergel@me.com> wrote: Let's have this discussion in the Pharo list.
Alexandre
Begin forwarded message:
From: Alexandre Bergel <alexandre.bergel@me.com> Subject: [Moose-dev] Re: Roassal new algorithms Date: April 19, 2013 11:25:31 AM GMT-04:00 To: Moose-related development <moose-dev@iam.unibe.ch> Reply-To: Moose-related development <moose-dev@iam.unibe.ch>
There are more than simply linear, quadratic and cubic Bezier curves. In fact, as you can have as many control points as you wish, you can have a Bezier curve of any order.
Ok
But what I was calling RadialBezierCurve was a kind of strategy, I mean I have an abstract class which knows how to compute a curve, but I still have to choose my control points so I was thinking to create different subclasses whose role is to know what are their control points :
- The radial one choose its control points within the same radius as its source and its target.
Ah ok
I wanted to create an ortoVertical and an ortoHorizontal whose control points would have been computed differently, so that we could use Bezier curve for regular tree too.
It would be cool to have hierarchical bundles edges in Roassal. A screenshot of what it looks like: <Screen Shot 2013-04-19 at 11.24.59 AM.png>
The technical description: http://www.win.tue.nl/~dholten/papers/bundles_infovis.pdf
Alexandre
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
-- Best regards, Igor Stasenko.
On 19 April 2013 20:39, Igor Stasenko <siguctua@gmail.com> wrote:
On 19 April 2013 21:33, Frank Shearar <frank.shearar@gmail.com> wrote:
Oh absolutely!
My comment comes from trying to analyse the dependencies between classes in my SIP stack [1]. What I found was that simply mapping dependencies in a flat namespace (as Delphi has) resulted in a tangled mess.
Oh.. SIP. RTP/RTCP been there , did that :) implementing it in C++ years ago.
Good times! I just wish I could find the data I used: I took the d3 sample and mucked around with it... and probably deleted it :/ frank
Then I added the unit name to the classes, so I had, say, IdSipTransport.TIdSipTransport. That resulted in a slightly less tangled mess: the strands started to bundle together.
Once I added a third layer - I grouped things into high level concepts like Transport, Transaction, Dialog, and so on - the strands bundled sufficiently tightly to actually be useful.
I suspect the same will hold true for Pharo (and Squeak). So if you turn names like "Debugger class in the Tools-Debugger package" into Tools.Debugger.Debugger you'd be well on your way.
frank
[1] https://github.com/frankshearar/SipStack
On 19 April 2013 19:57, Alexandre Bergel <alexandre.bergel@me.com> wrote:
This is a very cool visualization. There is no reason why we cannot do it in Pharo
Alexandre
On Apr 19, 2013, at 10:49 AM, Frank Shearar <frank.shearar@gmail.com> wrote:
I've played with these before [1]. They work best with hierarchical names. In other words, in a flat namespace (say, showing class dependencies with just the class name) you end up with a very messy diagram.
Let's assume you use "." as the name token separator. If you prefixed the names with their packages, say Tools-Debugger.Debugger, you'd get a better graph, where the bundles would be tighter. If you made things more hierarchical still, say with names like Tools.Debugger.Debugger, things would look even better.
The deeper the naming hierarchy the fewer fat bundles you get in the image.
frank
[1] http://mbostock.github.io/d3/talk/20111116/bundle.html
On 19 April 2013 16:37, Alexandre Bergel <alexandre.bergel@me.com> wrote: Let's have this discussion in the Pharo list.
Alexandre
Begin forwarded message:
From: Alexandre Bergel <alexandre.bergel@me.com> Subject: [Moose-dev] Re: Roassal new algorithms Date: April 19, 2013 11:25:31 AM GMT-04:00 To: Moose-related development <moose-dev@iam.unibe.ch> Reply-To: Moose-related development <moose-dev@iam.unibe.ch>
There are more than simply linear, quadratic and cubic Bezier curves. In fact, as you can have as many control points as you wish, you can have a Bezier curve of any order.
Ok
But what I was calling RadialBezierCurve was a kind of strategy, I mean I have an abstract class which knows how to compute a curve, but I still have to choose my control points so I was thinking to create different subclasses whose role is to know what are their control points :
- The radial one choose its control points within the same radius as its source and its target.
Ah ok
I wanted to create an ortoVertical and an ortoHorizontal whose control points would have been computed differently, so that we could use Bezier curve for regular tree too.
It would be cool to have hierarchical bundles edges in Roassal. A screenshot of what it looks like: <Screen Shot 2013-04-19 at 11.24.59 AM.png>
The technical description: http://www.win.tue.nl/~dholten/papers/bundles_infovis.pdf
Alexandre
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
-- Best regards, Igor Stasenko.
On 19 April 2013 20:45, Frank Shearar <frank.shearar@gmail.com> wrote:
On 19 April 2013 20:39, Igor Stasenko <siguctua@gmail.com> wrote:
On 19 April 2013 21:33, Frank Shearar <frank.shearar@gmail.com> wrote:
Oh absolutely!
My comment comes from trying to analyse the dependencies between classes in my SIP stack [1]. What I found was that simply mapping dependencies in a flat namespace (as Delphi has) resulted in a tangled mess.
Oh.. SIP. RTP/RTCP been there , did that :) implementing it in C++ years ago.
Good times! I just wish I could find the data I used: I took the d3 sample and mucked around with it... and probably deleted it :/
Found it! So I hacked a Ruby script to crawl over the Delphi source files and find inter-unit dependencies. Then I (manually) grouped units into RTP, Transport, Location, Transaction, Platform, and so on. Finally I manually grouped those groups into even higher level groups: SIP, Media, and so on. You can see the drastic effect on bundling that this grouping via hierarchical naming has. frank
frank
Then I added the unit name to the classes, so I had, say, IdSipTransport.TIdSipTransport. That resulted in a slightly less tangled mess: the strands started to bundle together.
Once I added a third layer - I grouped things into high level concepts like Transport, Transaction, Dialog, and so on - the strands bundled sufficiently tightly to actually be useful.
I suspect the same will hold true for Pharo (and Squeak). So if you turn names like "Debugger class in the Tools-Debugger package" into Tools.Debugger.Debugger you'd be well on your way.
frank
[1] https://github.com/frankshearar/SipStack
On 19 April 2013 19:57, Alexandre Bergel <alexandre.bergel@me.com> wrote:
This is a very cool visualization. There is no reason why we cannot do it in Pharo
Alexandre
On Apr 19, 2013, at 10:49 AM, Frank Shearar <frank.shearar@gmail.com> wrote:
I've played with these before [1]. They work best with hierarchical names. In other words, in a flat namespace (say, showing class dependencies with just the class name) you end up with a very messy diagram.
Let's assume you use "." as the name token separator. If you prefixed the names with their packages, say Tools-Debugger.Debugger, you'd get a better graph, where the bundles would be tighter. If you made things more hierarchical still, say with names like Tools.Debugger.Debugger, things would look even better.
The deeper the naming hierarchy the fewer fat bundles you get in the image.
frank
[1] http://mbostock.github.io/d3/talk/20111116/bundle.html
On 19 April 2013 16:37, Alexandre Bergel <alexandre.bergel@me.com> wrote: Let's have this discussion in the Pharo list.
Alexandre
Begin forwarded message:
From: Alexandre Bergel <alexandre.bergel@me.com> Subject: [Moose-dev] Re: Roassal new algorithms Date: April 19, 2013 11:25:31 AM GMT-04:00 To: Moose-related development <moose-dev@iam.unibe.ch> Reply-To: Moose-related development <moose-dev@iam.unibe.ch>
There are more than simply linear, quadratic and cubic Bezier curves. In fact, as you can have as many control points as you wish, you can have a Bezier curve of any order.
Ok
But what I was calling RadialBezierCurve was a kind of strategy, I mean I have an abstract class which knows how to compute a curve, but I still have to choose my control points so I was thinking to create different subclasses whose role is to know what are their control points :
- The radial one choose its control points within the same radius as its source and its target.
Ah ok
I wanted to create an ortoVertical and an ortoHorizontal whose control points would have been computed differently, so that we could use Bezier curve for regular tree too.
It would be cool to have hierarchical bundles edges in Roassal. A screenshot of what it looks like: <Screen Shot 2013-04-19 at 11.24.59 AM.png>
The technical description: http://www.win.tue.nl/~dholten/papers/bundles_infovis.pdf
Alexandre
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
-- Best regards, Igor Stasenko.
This visualization is precisely made for hierarchical graphs. That is why the edges are called "hierarchical bundled edges". So, yes, you need a hierarchical graph. Cheers, Doru On Apr 19, 2013, at 8:57 PM, Alexandre Bergel <alexandre.bergel@me.com> wrote:
This is a very cool visualization. There is no reason why we cannot do it in Pharo
Alexandre
On Apr 19, 2013, at 10:49 AM, Frank Shearar <frank.shearar@gmail.com> wrote:
I've played with these before [1]. They work best with hierarchical names. In other words, in a flat namespace (say, showing class dependencies with just the class name) you end up with a very messy diagram.
Let's assume you use "." as the name token separator. If you prefixed the names with their packages, say Tools-Debugger.Debugger, you'd get a better graph, where the bundles would be tighter. If you made things more hierarchical still, say with names like Tools.Debugger.Debugger, things would look even better.
The deeper the naming hierarchy the fewer fat bundles you get in the image.
frank
[1] http://mbostock.github.io/d3/talk/20111116/bundle.html
On 19 April 2013 16:37, Alexandre Bergel <alexandre.bergel@me.com> wrote: Let's have this discussion in the Pharo list.
Alexandre
Begin forwarded message:
From: Alexandre Bergel <alexandre.bergel@me.com> Subject: [Moose-dev] Re: Roassal new algorithms Date: April 19, 2013 11:25:31 AM GMT-04:00 To: Moose-related development <moose-dev@iam.unibe.ch> Reply-To: Moose-related development <moose-dev@iam.unibe.ch>
There are more than simply linear, quadratic and cubic Bezier curves. In fact, as you can have as many control points as you wish, you can have a Bezier curve of any order.
Ok
But what I was calling RadialBezierCurve was a kind of strategy, I mean I have an abstract class which knows how to compute a curve, but I still have to choose my control points so I was thinking to create different subclasses whose role is to know what are their control points :
- The radial one choose its control points within the same radius as its source and its target.
Ah ok
I wanted to create an ortoVertical and an ortoHorizontal whose control points would have been computed differently, so that we could use Bezier curve for regular tree too.
It would be cool to have hierarchical bundles edges in Roassal. A screenshot of what it looks like: <Screen Shot 2013-04-19 at 11.24.59 AM.png>
The technical description: http://www.win.tue.nl/~dholten/papers/bundles_infovis.pdf
Alexandre
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
-- www.tudorgirba.com "What is more important: To be happy, or to make happy?"
On Apr 20, 2013, at 8:23 AM, Tudor Girba <tudor@tudorgirba.com> wrote:
This visualization is precisely made for hierarchical graphs. That is why the edges are called "hierarchical bundled edges". So, yes, you need a hierarchical graph.
+1 :)
Cheers, Doru
On Apr 19, 2013, at 8:57 PM, Alexandre Bergel <alexandre.bergel@me.com> wrote:
This is a very cool visualization. There is no reason why we cannot do it in Pharo
Alexandre
On Apr 19, 2013, at 10:49 AM, Frank Shearar <frank.shearar@gmail.com> wrote:
I've played with these before [1]. They work best with hierarchical names. In other words, in a flat namespace (say, showing class dependencies with just the class name) you end up with a very messy diagram.
Let's assume you use "." as the name token separator. If you prefixed the names with their packages, say Tools-Debugger.Debugger, you'd get a better graph, where the bundles would be tighter. If you made things more hierarchical still, say with names like Tools.Debugger.Debugger, things would look even better.
The deeper the naming hierarchy the fewer fat bundles you get in the image.
frank
[1] http://mbostock.github.io/d3/talk/20111116/bundle.html
On 19 April 2013 16:37, Alexandre Bergel <alexandre.bergel@me.com> wrote: Let's have this discussion in the Pharo list.
Alexandre
Begin forwarded message:
From: Alexandre Bergel <alexandre.bergel@me.com> Subject: [Moose-dev] Re: Roassal new algorithms Date: April 19, 2013 11:25:31 AM GMT-04:00 To: Moose-related development <moose-dev@iam.unibe.ch> Reply-To: Moose-related development <moose-dev@iam.unibe.ch>
There are more than simply linear, quadratic and cubic Bezier curves. In fact, as you can have as many control points as you wish, you can have a Bezier curve of any order.
Ok
But what I was calling RadialBezierCurve was a kind of strategy, I mean I have an abstract class which knows how to compute a curve, but I still have to choose my control points so I was thinking to create different subclasses whose role is to know what are their control points :
- The radial one choose its control points within the same radius as its source and its target.
Ah ok
I wanted to create an ortoVertical and an ortoHorizontal whose control points would have been computed differently, so that we could use Bezier curve for regular tree too.
It would be cool to have hierarchical bundles edges in Roassal. A screenshot of what it looks like: <Screen Shot 2013-04-19 at 11.24.59 AM.png>
The technical description: http://www.win.tue.nl/~dholten/papers/bundles_infovis.pdf
Alexandre
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
-- www.tudorgirba.com
"What is more important: To be happy, or to make happy?"
Sure, and I had to discover that for myself, since the d3 example was titled "flare imports". I only found out about the name "hierarchical bundled edges" thanks to Alexandre's original post! frank On 20 April 2013 07:23, Tudor Girba <tudor@tudorgirba.com> wrote:
This visualization is precisely made for hierarchical graphs. That is why the edges are called "hierarchical bundled edges". So, yes, you need a hierarchical graph.
Cheers, Doru
On Apr 19, 2013, at 8:57 PM, Alexandre Bergel <alexandre.bergel@me.com> wrote:
This is a very cool visualization. There is no reason why we cannot do it in Pharo
Alexandre
On Apr 19, 2013, at 10:49 AM, Frank Shearar <frank.shearar@gmail.com> wrote:
I've played with these before [1]. They work best with hierarchical names. In other words, in a flat namespace (say, showing class dependencies with just the class name) you end up with a very messy diagram.
Let's assume you use "." as the name token separator. If you prefixed the names with their packages, say Tools-Debugger.Debugger, you'd get a better graph, where the bundles would be tighter. If you made things more hierarchical still, say with names like Tools.Debugger.Debugger, things would look even better.
The deeper the naming hierarchy the fewer fat bundles you get in the image.
frank
[1] http://mbostock.github.io/d3/talk/20111116/bundle.html
On 19 April 2013 16:37, Alexandre Bergel <alexandre.bergel@me.com> wrote: Let's have this discussion in the Pharo list.
Alexandre
Begin forwarded message:
From: Alexandre Bergel <alexandre.bergel@me.com> Subject: [Moose-dev] Re: Roassal new algorithms Date: April 19, 2013 11:25:31 AM GMT-04:00 To: Moose-related development <moose-dev@iam.unibe.ch> Reply-To: Moose-related development <moose-dev@iam.unibe.ch>
There are more than simply linear, quadratic and cubic Bezier curves. In fact, as you can have as many control points as you wish, you can have a Bezier curve of any order.
Ok
But what I was calling RadialBezierCurve was a kind of strategy, I mean I have an abstract class which knows how to compute a curve, but I still have to choose my control points so I was thinking to create different subclasses whose role is to know what are their control points :
- The radial one choose its control points within the same radius as its source and its target.
Ah ok
I wanted to create an ortoVertical and an ortoHorizontal whose control points would have been computed differently, so that we could use Bezier curve for regular tree too.
It would be cool to have hierarchical bundles edges in Roassal. A screenshot of what it looks like: <Screen Shot 2013-04-19 at 11.24.59 AM.png>
The technical description: http://www.win.tue.nl/~dholten/papers/bundles_infovis.pdf
Alexandre
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
-- www.tudorgirba.com
"What is more important: To be happy, or to make happy?"
participants (5)
-
Alexandre Bergel -
Frank Shearar -
Igor Stasenko -
stephane ducasse -
Tudor Girba