Hi,
I finished the first version of the new tree map builder for Roassal.
You can find the source code in my SmalltalkHub package 'DevFlow-View'!
Gofer new smalltalkhubUser: 'RobertoMinelli' project: 'DevFlow'; package: 'DevFlow-View'; load.
Here's an example usage:
builder := DFTreeMapBuilder new. builder weightBlock: [ :el | el ]. builder nodes: (1 to: 50). builder associations: (builder nodes allButFirst collect: [:each | (each // 2) -> each ]).
"Some optional configurations parameters" colors := Color white mix: Color blue shades: (builder nodes size). builder colorBlock: [ :el | colors at: el ]. builder rootColor: ((Color red) alpha: 0.5). builder inset: 5. builder extent: 500@300. builder origin: 10@30.
builder draw.
And the resulting tree map!
[cid:EC2669CC-CA97-4B81-8B1B-B792FBE1C04F@mobile.usilu.net]
Please tell me what do you think!
The next steps are: - Add customizable interactions - Remove z-ordering and use proper nesting - Eventually unroll the recursion in the layout algorithm
Cheers, Roberto
Looks good to me. Maybe you could have in addition to DFTreeMapBuilder>>associations: something DFTreeMapBuilder>>parent: aBlockOrASymbol
Also, something very important that I forgot to mention, we need a method DFTreeMapBuilder>>drawOn: aROView
Like that, we should be able to have a treemap when using the mondrian builder. Using your example, we should have exactly the same result if we do: -=-=-=-=-=-=-=-=-=-=-=-= builder := DFTreeMapBuilder new. builder ... // your example here
view := ROView new. builder drawOn: view. view open -=-=-=-=-=-=-=-=-=-=-=-=
Cheers, Alexandre
On Oct 7, 2013, at 1:07 PM, "roberto.minelli@usi.ch" roberto.minelli@usi.ch wrote:
Hi,
I finished the first version of the new tree map builder for Roassal.
You can find the source code in my SmalltalkHub package 'DevFlow-View'!
Gofer new smalltalkhubUser: 'RobertoMinelli' project: 'DevFlow'; package: 'DevFlow-View'; load.
Here's an example usage:
builder := DFTreeMapBuilder new. builder weightBlock: [ :el | el ]. builder nodes: (1 to: 50). builder associations: (builder nodes allButFirst collect: [:each | (each // 2) -> each ]).
"Some optional configurations parameters" colors := Color white mix: Color blue shades: (builder nodes size). builder colorBlock: [ :el | colors at: el ]. builder rootColor: ((Color red) alpha: 0.5). builder inset: 5. builder extent: 500@300. builder origin: 10@30.
builder draw.
And the resulting tree map!
[cid:EC2669CC-CA97-4B81-8B1B-B792FBE1C04F@mobile.usilu.net]
Please tell me what do you think!
The next steps are:
- Add customizable interactions
- Remove z-ordering and use proper nesting
- Eventually unroll the recursion in the layout algorithm
Cheers, Roberto
Hi,
I made a couple of changes of the builder as per your suggestions. An updated usage script would be:
builder := DFTreeMapBuilder new. builder weightBlock: [ :el | el ]. builder nodes: (1 to: 50). builder nestingFromAssociations: (builder nodes allButFirst collect: [:each | (each // 2) -> each ]).
"Some optional configurations parameters" colors := Color green mix: Color blue shades: (builder nodes size). builder colorBlock: [ :el | colors at: el ]. builder rootColor: ((Color red) alpha: 0.5). builder inset: 5. builder extent: 300@400. builder origin: 10@30.
"Some node-specific customization" builder fillNodes: [ :n | (n > 40) ] withColor: (Color white). builder fillNode: 50 withColor: (Color yellow). builder fillNode: 43 withColor: (Color green).
builder strokeNodes: [ :n | (n \ 2) = 1 ] withColor: (Color blue). builder strokeNode: 13 withColor: (Color black).
builder strokeNodes: [ :n | (n \ 6) = 0 ] withWidth: 2. builder strokeNode: 3 withColor: (Color red). builder strokeNode: 3 withWidth: 3.
"Using the #drawOn: message for compatibility with ROMondrianViewBuilder" view := ROView new. view @ RODraggable. builder drawOn: view. view open.
And the resulting tree map @ https://dl.dropboxusercontent.com/u/6281855/updated-treemap.png
Now I am converting from z-ordering to nesting. Stay tuned ;)
Cheers, Roby
On Oct 7, 2013, at 7:33 PM, Alexandre Bergel alexandre.bergel@me.com wrote:
Looks good to me. Maybe you could have in addition to DFTreeMapBuilder>>associations: something DFTreeMapBuilder>>parent: aBlockOrASymbol
Also, something very important that I forgot to mention, we need a method DFTreeMapBuilder>>drawOn: aROView
Like that, we should be able to have a treemap when using the mondrian builder. Using your example, we should have exactly the same result if we do:
builder := DFTreeMapBuilder new. builder ... // your example here
view := ROView new. builder drawOn: view. view open -=-=-=-=-=-=-=-=-=-=-=-=
Cheers, Alexandre
On Oct 7, 2013, at 1:07 PM, "roberto.minelli@usi.ch" roberto.minelli@usi.ch wrote:
Hi,
I finished the first version of the new tree map builder for Roassal.
You can find the source code in my SmalltalkHub package 'DevFlow-View'!
Gofer new smalltalkhubUser: 'RobertoMinelli' project: 'DevFlow'; package: 'DevFlow-View'; load.
Here's an example usage:
builder := DFTreeMapBuilder new. builder weightBlock: [ :el | el ]. builder nodes: (1 to: 50). builder associations: (builder nodes allButFirst collect: [:each | (each // 2) -> each ]).
"Some optional configurations parameters" colors := Color white mix: Color blue shades: (builder nodes size). builder colorBlock: [ :el | colors at: el ]. builder rootColor: ((Color red) alpha: 0.5). builder inset: 5. builder extent: 500@300. builder origin: 10@30.
builder draw.
And the resulting tree map!
[cid:EC2669CC-CA97-4B81-8B1B-B792FBE1C04F@mobile.usilu.net]
Please tell me what do you think!
The next steps are:
- Add customizable interactions
- Remove z-ordering and use proper nesting
- Eventually unroll the recursion in the layout algorithm
Cheers, Roberto
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Ok, excellent!!!
Alexandre
Le 08-10-2013 à 6:44, "roberto.minelli@usi.ch" roberto.minelli@usi.ch a écrit :
Hi,
I made a couple of changes of the builder as per your suggestions. An updated usage script would be:
builder := DFTreeMapBuilder new. builder weightBlock: [ :el | el ]. builder nodes: (1 to: 50). builder nestingFromAssociations: (builder nodes allButFirst collect: [:each | (each // 2) -> each ]).
"Some optional configurations parameters" colors := Color green mix: Color blue shades: (builder nodes size). builder colorBlock: [ :el | colors at: el ]. builder rootColor: ((Color red) alpha: 0.5). builder inset: 5. builder extent: 300@400. builder origin: 10@30.
"Some node-specific customization" builder fillNodes: [ :n | (n > 40) ] withColor: (Color white). builder fillNode: 50 withColor: (Color yellow). builder fillNode: 43 withColor: (Color green).
builder strokeNodes: [ :n | (n \ 2) = 1 ] withColor: (Color blue). builder strokeNode: 13 withColor: (Color black).
builder strokeNodes: [ :n | (n \ 6) = 0 ] withWidth: 2. builder strokeNode: 3 withColor: (Color red). builder strokeNode: 3 withWidth: 3.
"Using the #drawOn: message for compatibility with ROMondrianViewBuilder" view := ROView new. view @ RODraggable. builder drawOn: view. view open.
And the resulting tree map @ https://dl.dropboxusercontent.com/u/6281855/updated-treemap.png
Now I am converting from z-ordering to nesting. Stay tuned ;)
Cheers, Roby
On Oct 7, 2013, at 7:33 PM, Alexandre Bergel alexandre.bergel@me.com wrote:
Looks good to me. Maybe you could have in addition to DFTreeMapBuilder>>associations: something DFTreeMapBuilder>>parent: aBlockOrASymbol
Also, something very important that I forgot to mention, we need a method DFTreeMapBuilder>>drawOn: aROView
Like that, we should be able to have a treemap when using the mondrian builder. Using your example, we should have exactly the same result if we do:
builder := DFTreeMapBuilder new. builder ... // your example here
view := ROView new. builder drawOn: view. view open -=-=-=-=-=-=-=-=-=-=-=-=
Cheers, Alexandre
On Oct 7, 2013, at 1:07 PM, "roberto.minelli@usi.ch" roberto.minelli@usi.ch wrote:
Hi,
I finished the first version of the new tree map builder for Roassal.
You can find the source code in my SmalltalkHub package 'DevFlow-View'!
Gofer new smalltalkhubUser: 'RobertoMinelli' project: 'DevFlow'; package: 'DevFlow-View'; load.
Here's an example usage:
builder := DFTreeMapBuilder new. builder weightBlock: [ :el | el ]. builder nodes: (1 to: 50). builder associations: (builder nodes allButFirst collect: [:each | (each // 2) -> each ]).
"Some optional configurations parameters" colors := Color white mix: Color blue shades: (builder nodes size). builder colorBlock: [ :el | colors at: el ]. builder rootColor: ((Color red) alpha: 0.5). builder inset: 5. builder extent: 500@300. builder origin: 10@30.
builder draw.
And the resulting tree map!
[cid:EC2669CC-CA97-4B81-8B1B-B792FBE1C04F@mobile.usilu.net]
Please tell me what do you think!
The next steps are:
- Add customizable interactions
- Remove z-ordering and use proper nesting
- Eventually unroll the recursion in the layout algorithm
Cheers, Roberto
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
And yes, now the tree map builder does no longer use z-ordering to lay out the elements ;)
On Oct 8, 2013, at 12:51 PM, Alexandre Bergel alexandre.bergel@me.com wrote:
Ok, excellent!!!
Alexandre
Le 08-10-2013 à 6:44, "roberto.minelli@usi.ch" roberto.minelli@usi.ch a écrit :
Hi,
I made a couple of changes of the builder as per your suggestions. An updated usage script would be:
builder := DFTreeMapBuilder new. builder weightBlock: [ :el | el ]. builder nodes: (1 to: 50). builder nestingFromAssociations: (builder nodes allButFirst collect: [:each | (each // 2) -> each ]).
"Some optional configurations parameters" colors := Color green mix: Color blue shades: (builder nodes size). builder colorBlock: [ :el | colors at: el ]. builder rootColor: ((Color red) alpha: 0.5). builder inset: 5. builder extent: 300@400. builder origin: 10@30.
"Some node-specific customization" builder fillNodes: [ :n | (n > 40) ] withColor: (Color white). builder fillNode: 50 withColor: (Color yellow). builder fillNode: 43 withColor: (Color green).
builder strokeNodes: [ :n | (n \ 2) = 1 ] withColor: (Color blue). builder strokeNode: 13 withColor: (Color black).
builder strokeNodes: [ :n | (n \ 6) = 0 ] withWidth: 2. builder strokeNode: 3 withColor: (Color red). builder strokeNode: 3 withWidth: 3.
"Using the #drawOn: message for compatibility with ROMondrianViewBuilder" view := ROView new. view @ RODraggable. builder drawOn: view. view open.
And the resulting tree map @ https://dl.dropboxusercontent.com/u/6281855/updated-treemap.png
Now I am converting from z-ordering to nesting. Stay tuned ;)
Cheers, Roby
On Oct 7, 2013, at 7:33 PM, Alexandre Bergel alexandre.bergel@me.com wrote:
Looks good to me. Maybe you could have in addition to DFTreeMapBuilder>>associations: something DFTreeMapBuilder>>parent: aBlockOrASymbol
Also, something very important that I forgot to mention, we need a method DFTreeMapBuilder>>drawOn: aROView
Like that, we should be able to have a treemap when using the mondrian builder. Using your example, we should have exactly the same result if we do:
builder := DFTreeMapBuilder new. builder ... // your example here
view := ROView new. builder drawOn: view. view open -=-=-=-=-=-=-=-=-=-=-=-=
Cheers, Alexandre
On Oct 7, 2013, at 1:07 PM, "roberto.minelli@usi.ch" roberto.minelli@usi.ch wrote:
Hi,
I finished the first version of the new tree map builder for Roassal.
You can find the source code in my SmalltalkHub package 'DevFlow-View'!
Gofer new smalltalkhubUser: 'RobertoMinelli' project: 'DevFlow'; package: 'DevFlow-View'; load.
Here's an example usage:
builder := DFTreeMapBuilder new. builder weightBlock: [ :el | el ]. builder nodes: (1 to: 50). builder associations: (builder nodes allButFirst collect: [:each | (each // 2) -> each ]).
"Some optional configurations parameters" colors := Color white mix: Color blue shades: (builder nodes size). builder colorBlock: [ :el | colors at: el ]. builder rootColor: ((Color red) alpha: 0.5). builder inset: 5. builder extent: 500@300. builder origin: 10@30.
builder draw.
And the resulting tree map!
[cid:EC2669CC-CA97-4B81-8B1B-B792FBE1C04F@mobile.usilu.net]
Please tell me what do you think!
The next steps are:
- Add customizable interactions
- Remove z-ordering and use proper nesting
- Eventually unroll the recursion in the layout algorithm
Cheers, Roberto
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Here is another way to visualize the nesting, with frames. It's enough to call #withShadedFrames. How cool is that?
Here's a sample visualization @ https://dl.dropboxusercontent.com/u/6281855/treemap-frames.png
And here's the script: =-=-=--=-=-=-=-=-=--=-=-=-=-=-=--=-=-=-=-=-=--=-=-=-=-=-=--=-=-=-=-=-=--=-=-=-=-=-=--=-=-=-=-=-=--=-=-=-
builder := DFTreeMapBuilder new. builder weightBlock: [ :el | el ]. builder nodes: (1 to: 100). builder nestingFromAssociations: (builder nodes allButFirst collect: [:each | (each // 2) -> each ]).
"Some optional configurations parameters" colors := (Color lightBlue) mix: Color blue shades: (builder nodes size). builder colorBlock: [ :el | colors at: el ]. builder rootColor: (Color red). builder extent: 521@312. builder origin: 20@20.
builder withShadedFrames.
builder draw. =-=-=--=-=-=-=-=-=--=-=-=-=-=-=--=-=-=-=-=-=--=-=-=-=-=-=--=-=-=-=-=-=--=-=-=-=-=-=--=-=-=-=-=-=--=-=-=- Roby
On Oct 9, 2013, at 8:12 AM, "roberto.minelli@usi.ch" roberto.minelli@usi.ch wrote:
And yes, now the tree map builder does no longer use z-ordering to lay out the elements ;)
On Oct 8, 2013, at 12:51 PM, Alexandre Bergel alexandre.bergel@me.com wrote:
Ok, excellent!!!
Alexandre
Le 08-10-2013 à 6:44, "roberto.minelli@usi.ch" roberto.minelli@usi.ch a écrit :
Hi,
I made a couple of changes of the builder as per your suggestions. An updated usage script would be:
builder := DFTreeMapBuilder new. builder weightBlock: [ :el | el ]. builder nodes: (1 to: 50). builder nestingFromAssociations: (builder nodes allButFirst collect: [:each | (each // 2) -> each ]).
"Some optional configurations parameters" colors := Color green mix: Color blue shades: (builder nodes size). builder colorBlock: [ :el | colors at: el ]. builder rootColor: ((Color red) alpha: 0.5). builder inset: 5. builder extent: 300@400. builder origin: 10@30.
"Some node-specific customization" builder fillNodes: [ :n | (n > 40) ] withColor: (Color white). builder fillNode: 50 withColor: (Color yellow). builder fillNode: 43 withColor: (Color green).
builder strokeNodes: [ :n | (n \ 2) = 1 ] withColor: (Color blue). builder strokeNode: 13 withColor: (Color black).
builder strokeNodes: [ :n | (n \ 6) = 0 ] withWidth: 2. builder strokeNode: 3 withColor: (Color red). builder strokeNode: 3 withWidth: 3.
"Using the #drawOn: message for compatibility with ROMondrianViewBuilder" view := ROView new. view @ RODraggable. builder drawOn: view. view open.
And the resulting tree map @ https://dl.dropboxusercontent.com/u/6281855/updated-treemap.png
Now I am converting from z-ordering to nesting. Stay tuned ;)
Cheers, Roby
On Oct 7, 2013, at 7:33 PM, Alexandre Bergel alexandre.bergel@me.com wrote:
Looks good to me. Maybe you could have in addition to DFTreeMapBuilder>>associations: something DFTreeMapBuilder>>parent: aBlockOrASymbol
Also, something very important that I forgot to mention, we need a method DFTreeMapBuilder>>drawOn: aROView
Like that, we should be able to have a treemap when using the mondrian builder. Using your example, we should have exactly the same result if we do:
builder := DFTreeMapBuilder new. builder ... // your example here
view := ROView new. builder drawOn: view. view open -=-=-=-=-=-=-=-=-=-=-=-=
Cheers, Alexandre
On Oct 7, 2013, at 1:07 PM, "roberto.minelli@usi.ch" roberto.minelli@usi.ch wrote:
Hi,
I finished the first version of the new tree map builder for Roassal.
You can find the source code in my SmalltalkHub package 'DevFlow-View'!
Gofer new smalltalkhubUser: 'RobertoMinelli' project: 'DevFlow'; package: 'DevFlow-View'; load.
Here's an example usage:
builder := DFTreeMapBuilder new. builder weightBlock: [ :el | el ]. builder nodes: (1 to: 50). builder associations: (builder nodes allButFirst collect: [:each | (each // 2) -> each ]).
"Some optional configurations parameters" colors := Color white mix: Color blue shades: (builder nodes size). builder colorBlock: [ :el | colors at: el ]. builder rootColor: ((Color red) alpha: 0.5). builder inset: 5. builder extent: 500@300. builder origin: 10@30.
builder draw.
And the resulting tree map!
[cid:EC2669CC-CA97-4B81-8B1B-B792FBE1C04F@mobile.usilu.net]
Please tell me what do you think!
The next steps are:
- Add customizable interactions
- Remove z-ordering and use proper nesting
- Eventually unroll the recursion in the layout algorithm
Cheers, Roberto
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
404 on dropbox
On Oct 9, 2013, at 9:30 AM, roberto.minelli@usi.ch wrote:
Here is another way to visualize the nesting, with frames. It's enough to call #withShadedFrames. How cool is that?
Here's a sample visualization @ https://dl.dropboxusercontent.com/u/6281855/treemap-frames.png
And here's the script:
builder := DFTreeMapBuilder new. builder weightBlock: [ :el | el ]. builder nodes: (1 to: 100). builder nestingFromAssociations: (builder nodes allButFirst collect: [:each | (each // 2) -> each ]).
"Some optional configurations parameters" colors := (Color lightBlue) mix: Color blue shades: (builder nodes size). builder colorBlock: [ :el | colors at: el ]. builder rootColor: (Color red). builder extent: 521@312. builder origin: 20@20.
builder withShadedFrames.
builder draw.
Roby
On Oct 9, 2013, at 8:12 AM, "roberto.minelli@usi.ch" roberto.minelli@usi.ch wrote:
And yes, now the tree map builder does no longer use z-ordering to lay out the elements ;)
On Oct 8, 2013, at 12:51 PM, Alexandre Bergel alexandre.bergel@me.com wrote:
Ok, excellent!!!
Alexandre
Le 08-10-2013 à 6:44, "roberto.minelli@usi.ch" roberto.minelli@usi.ch a écrit :
Hi,
I made a couple of changes of the builder as per your suggestions. An updated usage script would be:
builder := DFTreeMapBuilder new. builder weightBlock: [ :el | el ]. builder nodes: (1 to: 50). builder nestingFromAssociations: (builder nodes allButFirst collect: [:each | (each // 2) -> each ]).
"Some optional configurations parameters" colors := Color green mix: Color blue shades: (builder nodes size). builder colorBlock: [ :el | colors at: el ]. builder rootColor: ((Color red) alpha: 0.5). builder inset: 5. builder extent: 300@400. builder origin: 10@30.
"Some node-specific customization" builder fillNodes: [ :n | (n > 40) ] withColor: (Color white). builder fillNode: 50 withColor: (Color yellow). builder fillNode: 43 withColor: (Color green).
builder strokeNodes: [ :n | (n \ 2) = 1 ] withColor: (Color blue). builder strokeNode: 13 withColor: (Color black).
builder strokeNodes: [ :n | (n \ 6) = 0 ] withWidth: 2. builder strokeNode: 3 withColor: (Color red). builder strokeNode: 3 withWidth: 3.
"Using the #drawOn: message for compatibility with ROMondrianViewBuilder" view := ROView new. view @ RODraggable. builder drawOn: view. view open.
And the resulting tree map @ https://dl.dropboxusercontent.com/u/6281855/updated-treemap.png
Now I am converting from z-ordering to nesting. Stay tuned ;)
Cheers, Roby
On Oct 7, 2013, at 7:33 PM, Alexandre Bergel alexandre.bergel@me.com wrote:
Looks good to me. Maybe you could have in addition to DFTreeMapBuilder>>associations: something DFTreeMapBuilder>>parent: aBlockOrASymbol
Also, something very important that I forgot to mention, we need a method DFTreeMapBuilder>>drawOn: aROView
Like that, we should be able to have a treemap when using the mondrian builder. Using your example, we should have exactly the same result if we do:
builder := DFTreeMapBuilder new. builder ... // your example here
view := ROView new. builder drawOn: view. view open -=-=-=-=-=-=-=-=-=-=-=-=
Cheers, Alexandre
On Oct 7, 2013, at 1:07 PM, "roberto.minelli@usi.ch" roberto.minelli@usi.ch wrote:
Hi,
I finished the first version of the new tree map builder for Roassal.
You can find the source code in my SmalltalkHub package 'DevFlow-View'!
Gofer new smalltalkhubUser: 'RobertoMinelli' project: 'DevFlow'; package: 'DevFlow-View'; load.
Here's an example usage:
builder := DFTreeMapBuilder new. builder weightBlock: [ :el | el ]. builder nodes: (1 to: 50). builder associations: (builder nodes allButFirst collect: [:each | (each // 2) -> each ]).
"Some optional configurations parameters" colors := Color white mix: Color blue shades: (builder nodes size). builder colorBlock: [ :el | colors at: el ]. builder rootColor: ((Color red) alpha: 0.5). builder inset: 5. builder extent: 500@300. builder origin: 10@30.
builder draw.
And the resulting tree map!
[cid:EC2669CC-CA97-4B81-8B1B-B792FBE1C04F@mobile.usilu.net]
Please tell me what do you think!
The next steps are:
- Add customizable interactions
- Remove z-ordering and use proper nesting
- Eventually unroll the recursion in the layout algorithm
Cheers, Roberto
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: 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
Sorry, DropBox messed up the image name. I updated the file ;)
On Oct 9, 2013, at 9:57 AM, Yuriy Tymchuk yuriy.tymchuk@me.com wrote:
404 on dropbox
On Oct 9, 2013, at 9:30 AM, roberto.minelli@usi.ch wrote:
Here is another way to visualize the nesting, with frames. It's enough to call #withShadedFrames. How cool is that?
Here's a sample visualization @ https://dl.dropboxusercontent.com/u/6281855/treemap-frames.png
And here's the script:
builder := DFTreeMapBuilder new. builder weightBlock: [ :el | el ]. builder nodes: (1 to: 100). builder nestingFromAssociations: (builder nodes allButFirst collect: [:each | (each // 2) -> each ]).
"Some optional configurations parameters" colors := (Color lightBlue) mix: Color blue shades: (builder nodes size). builder colorBlock: [ :el | colors at: el ]. builder rootColor: (Color red). builder extent: 521@312. builder origin: 20@20.
builder withShadedFrames.
builder draw.
Roby
On Oct 9, 2013, at 8:12 AM, "roberto.minelli@usi.ch" roberto.minelli@usi.ch wrote:
And yes, now the tree map builder does no longer use z-ordering to lay out the elements ;)
On Oct 8, 2013, at 12:51 PM, Alexandre Bergel alexandre.bergel@me.com wrote:
Ok, excellent!!!
Alexandre
Le 08-10-2013 à 6:44, "roberto.minelli@usi.ch" roberto.minelli@usi.ch a écrit :
Hi,
I made a couple of changes of the builder as per your suggestions. An updated usage script would be:
builder := DFTreeMapBuilder new. builder weightBlock: [ :el | el ]. builder nodes: (1 to: 50). builder nestingFromAssociations: (builder nodes allButFirst collect: [:each | (each // 2) -> each ]).
"Some optional configurations parameters" colors := Color green mix: Color blue shades: (builder nodes size). builder colorBlock: [ :el | colors at: el ]. builder rootColor: ((Color red) alpha: 0.5). builder inset: 5. builder extent: 300@400. builder origin: 10@30.
"Some node-specific customization" builder fillNodes: [ :n | (n > 40) ] withColor: (Color white). builder fillNode: 50 withColor: (Color yellow). builder fillNode: 43 withColor: (Color green).
builder strokeNodes: [ :n | (n \ 2) = 1 ] withColor: (Color blue). builder strokeNode: 13 withColor: (Color black).
builder strokeNodes: [ :n | (n \ 6) = 0 ] withWidth: 2. builder strokeNode: 3 withColor: (Color red). builder strokeNode: 3 withWidth: 3.
"Using the #drawOn: message for compatibility with ROMondrianViewBuilder" view := ROView new. view @ RODraggable. builder drawOn: view. view open.
And the resulting tree map @ https://dl.dropboxusercontent.com/u/6281855/updated-treemap.png
Now I am converting from z-ordering to nesting. Stay tuned ;)
Cheers, Roby
On Oct 7, 2013, at 7:33 PM, Alexandre Bergel alexandre.bergel@me.com wrote:
Looks good to me. Maybe you could have in addition to DFTreeMapBuilder>>associations: something DFTreeMapBuilder>>parent: aBlockOrASymbol
Also, something very important that I forgot to mention, we need a method DFTreeMapBuilder>>drawOn: aROView
Like that, we should be able to have a treemap when using the mondrian builder. Using your example, we should have exactly the same result if we do:
builder := DFTreeMapBuilder new. builder ... // your example here
view := ROView new. builder drawOn: view. view open -=-=-=-=-=-=-=-=-=-=-=-=
Cheers, Alexandre
> On Oct 7, 2013, at 1:07 PM, "roberto.minelli@usi.ch" roberto.minelli@usi.ch wrote: > > Hi, > > I finished the first version of the new tree map builder for Roassal. > > You can find the source code in my SmalltalkHub package 'DevFlow-View'! > > Gofer new > smalltalkhubUser: 'RobertoMinelli' project: 'DevFlow'; > package: 'DevFlow-View'; > load. > > Here's an example usage: > > builder := DFTreeMapBuilder new. > builder weightBlock: [ :el | el ]. > builder nodes: (1 to: 50). > builder associations: (builder nodes allButFirst collect: [:each | (each // 2) -> each ]). > > "Some optional configurations parameters" > colors := Color white mix: Color blue shades: (builder nodes size). > builder colorBlock: [ :el | colors at: el ]. > builder rootColor: ((Color red) alpha: 0.5). > builder inset: 5. > builder extent: 500@300. > builder origin: 10@30. > > builder draw. > > And the resulting tree map! > > [cid:EC2669CC-CA97-4B81-8B1B-B792FBE1C04F@mobile.usilu.net] > > Please tell me what do you think! > > The next steps are: > - Add customizable interactions > - Remove z-ordering and use proper nesting > - Eventually unroll the recursion in the layout algorithm > > Cheers, > Roberto
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: 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
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Nice!
I just do not understand why colors has the same size as the nodes collection. It should have the same size as the max nesting level. What do I get wrong?
In any case, I think for shading we need also strategy that hides the implementation details (so, no explicit color creation). I think that we can just give a min and a max and then simply use a linear color normalizer internally. Of course, we also need a way to marry such an implicit strategy with the possibility of custom colors :). Proposals?
Doru
On Wed, Oct 9, 2013 at 10:02 AM, roberto.minelli@usi.ch < roberto.minelli@usi.ch> wrote:
Sorry, DropBox messed up the image name. I updated the file ;)
On Oct 9, 2013, at 9:57 AM, Yuriy Tymchuk yuriy.tymchuk@me.com wrote:
404 on dropbox
On Oct 9, 2013, at 9:30 AM, roberto.minelli@usi.ch wrote:
Here is another way to visualize the nesting, with frames. It's enough
to call #withShadedFrames. How cool is that?
Here's a sample visualization @
https://dl.dropboxusercontent.com/u/6281855/treemap-frames.png
And here's the script:
=-=-=--=-=-=-=-=-=--=-=-=-=-=-=--=-=-=-=-=-=--=-=-=-=-=-=--=-=-=-=-=-=--=-=-=-=-=-=--=-=-=-=-=-=--=-=-=-
builder := DFTreeMapBuilder new. builder weightBlock: [ :el | el ]. builder nodes: (1 to: 100). builder nestingFromAssociations: (builder nodes allButFirst collect:
[:each | (each // 2) -> each ]).
"Some optional configurations parameters" colors := (Color lightBlue) mix: Color blue shades: (builder nodes
size).
builder colorBlock: [ :el | colors at: el ]. builder rootColor: (Color red). builder extent: 521@312. builder origin: 20@20.
builder withShadedFrames.
builder draw.
=-=-=--=-=-=-=-=-=--=-=-=-=-=-=--=-=-=-=-=-=--=-=-=-=-=-=--=-=-=-=-=-=--=-=-=-=-=-=--=-=-=-=-=-=--=-=-=-
Roby
On Oct 9, 2013, at 8:12 AM, "roberto.minelli@usi.ch" <
roberto.minelli@usi.ch>
wrote:
And yes, now the tree map builder does no longer use z-ordering to lay
out the elements ;)
On Oct 8, 2013, at 12:51 PM, Alexandre Bergel alexandre.bergel@me.com
wrote:
Ok, excellent!!!
Alexandre
Le 08-10-2013 à 6:44, "roberto.minelli@usi.ch" <
roberto.minelli@usi.ch> a écrit :
Hi,
I made a couple of changes of the builder as per your suggestions.
An updated usage script would be:
> builder := DFTreeMapBuilder new. > builder weightBlock: [ :el | el ]. > builder nodes: (1 to: 50). > builder nestingFromAssociations: (builder nodes allButFirst
collect: [:each | (each // 2) -> each ]).
> > "Some optional configurations parameters" > colors := Color green mix: Color blue shades: (builder nodes size). > builder colorBlock: [ :el | colors at: el ]. > builder rootColor: ((Color red) alpha: 0.5). > builder inset: 5. > builder extent: 300@400. > builder origin: 10@30. > > "Some node-specific customization" > builder fillNodes: [ :n | (n > 40) ] withColor: (Color white). > builder fillNode: 50 withColor: (Color yellow). > builder fillNode: 43 withColor: (Color green). > > builder strokeNodes: [ :n | (n \ 2) = 1 ] withColor: (Color blue). > builder strokeNode: 13 withColor: (Color black). > > builder strokeNodes: [ :n | (n \ 6) = 0 ] withWidth: 2. > builder strokeNode: 3 withColor: (Color red). > builder strokeNode: 3 withWidth: 3. > > "Using the #drawOn: message for compatibility with
ROMondrianViewBuilder"
> view := ROView new. > view @ RODraggable. > builder drawOn: view. > view open.
And the resulting tree map @
https://dl.dropboxusercontent.com/u/6281855/updated-treemap.png
Now I am converting from z-ordering to nesting. Stay tuned ;)
Cheers, Roby
> On Oct 7, 2013, at 7:33 PM, Alexandre Bergel <
alexandre.bergel@me.com> wrote:
> > Looks good to me. > Maybe you could have in addition to > DFTreeMapBuilder>>associations: > something > DFTreeMapBuilder>>parent: aBlockOrASymbol > > Also, something very important that I forgot to mention, we need a
method DFTreeMapBuilder>>drawOn: aROView
> > Like that, we should be able to have a treemap when using the
mondrian builder. Using your example, we should have exactly the same result if we do:
> -=-=-=-=-=-=-=-=-=-=-=-= > builder := DFTreeMapBuilder new. > builder ... // your example here > > view := ROView new. > builder drawOn: view. > view open > -=-=-=-=-=-=-=-=-=-=-=-= > > Cheers, > Alexandre > > >> On Oct 7, 2013, at 1:07 PM, "roberto.minelli@usi.ch" <
roberto.minelli@usi.ch> wrote:
>> >> Hi, >> >> I finished the first version of the new tree map builder for
Roassal.
>> >> You can find the source code in my SmalltalkHub package
'DevFlow-View'!
>> >> Gofer new >> smalltalkhubUser: 'RobertoMinelli' project: 'DevFlow'; >> package: 'DevFlow-View'; >> load. >> >> Here's an example usage: >> >> builder := DFTreeMapBuilder new. >> builder weightBlock: [ :el | el ]. >> builder nodes: (1 to: 50). >> builder associations: (builder nodes allButFirst collect: [:each |
(each // 2) -> each ]).
>> >> "Some optional configurations parameters" >> colors := Color white mix: Color blue shades: (builder nodes size). >> builder colorBlock: [ :el | colors at: el ]. >> builder rootColor: ((Color red) alpha: 0.5). >> builder inset: 5. >> builder extent: 500@300. >> builder origin: 10@30. >> >> builder draw. >> >> And the resulting tree map! >> >> [cid:EC2669CC-CA97-4B81-8B1B-B792FBE1C04F@mobile.usilu.net] >> >> Please tell me what do you think! >> >> The next steps are: >> - Add customizable interactions >> - Remove z-ordering and use proper nesting >> - Eventually unroll the recursion in the layout algorithm >> >> Cheers, >> Roberto > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > 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
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
Ok, I took a closer look and you already implemented almost what I said :).
So, let's take a look: withShadedFrames self inset: 1. self strokeAllNodesWithColorBlock: [ :el | Color darkGray darker adjustSaturation: (-0.03 * el depth) brightness: (el depth * 0.08). ].
This is a good start, but: - Color darkGray should not be hardcoded - The actual darkening strategy should not be hardcoded either
I would suggest to use a LinearColorNormalizer instead. This allows you to specify both the min and max color. What do you say?
Cheers, Doru
On Wed, Oct 9, 2013 at 10:11 AM, Tudor Girba tudor@tudorgirba.com wrote:
Nice!
I just do not understand why colors has the same size as the nodes collection. It should have the same size as the max nesting level. What do I get wrong?
In any case, I think for shading we need also strategy that hides the implementation details (so, no explicit color creation). I think that we can just give a min and a max and then simply use a linear color normalizer internally. Of course, we also need a way to marry such an implicit strategy with the possibility of custom colors :). Proposals?
Doru
On Wed, Oct 9, 2013 at 10:02 AM, roberto.minelli@usi.ch < roberto.minelli@usi.ch> wrote:
Sorry, DropBox messed up the image name. I updated the file ;)
On Oct 9, 2013, at 9:57 AM, Yuriy Tymchuk yuriy.tymchuk@me.com wrote:
404 on dropbox
On Oct 9, 2013, at 9:30 AM, roberto.minelli@usi.ch wrote:
Here is another way to visualize the nesting, with frames. It's enough
to call #withShadedFrames. How cool is that?
Here's a sample visualization @
https://dl.dropboxusercontent.com/u/6281855/treemap-frames.png
And here's the script:
=-=-=--=-=-=-=-=-=--=-=-=-=-=-=--=-=-=-=-=-=--=-=-=-=-=-=--=-=-=-=-=-=--=-=-=-=-=-=--=-=-=-=-=-=--=-=-=-
builder := DFTreeMapBuilder new. builder weightBlock: [ :el | el ]. builder nodes: (1 to: 100). builder nestingFromAssociations: (builder nodes allButFirst collect:
[:each | (each // 2) -> each ]).
"Some optional configurations parameters" colors := (Color lightBlue) mix: Color blue shades: (builder nodes
size).
builder colorBlock: [ :el | colors at: el ]. builder rootColor: (Color red). builder extent: 521@312. builder origin: 20@20.
builder withShadedFrames.
builder draw.
=-=-=--=-=-=-=-=-=--=-=-=-=-=-=--=-=-=-=-=-=--=-=-=-=-=-=--=-=-=-=-=-=--=-=-=-=-=-=--=-=-=-=-=-=--=-=-=-
Roby
On Oct 9, 2013, at 8:12 AM, "roberto.minelli@usi.ch" <
roberto.minelli@usi.ch>
wrote:
And yes, now the tree map builder does no longer use z-ordering to
lay out the elements ;)
On Oct 8, 2013, at 12:51 PM, Alexandre Bergel <
alexandre.bergel@me.com> wrote:
Ok, excellent!!!
Alexandre
> Le 08-10-2013 à 6:44, "roberto.minelli@usi.ch" <
roberto.minelli@usi.ch> a écrit :
> > Hi, > > I made a couple of changes of the builder as per your suggestions.
An updated usage script would be:
> >> builder := DFTreeMapBuilder new. >> builder weightBlock: [ :el | el ]. >> builder nodes: (1 to: 50). >> builder nestingFromAssociations: (builder nodes allButFirst
collect: [:each | (each // 2) -> each ]).
>> >> "Some optional configurations parameters" >> colors := Color green mix: Color blue shades: (builder nodes size). >> builder colorBlock: [ :el | colors at: el ]. >> builder rootColor: ((Color red) alpha: 0.5). >> builder inset: 5. >> builder extent: 300@400. >> builder origin: 10@30. >> >> "Some node-specific customization" >> builder fillNodes: [ :n | (n > 40) ] withColor: (Color white). >> builder fillNode: 50 withColor: (Color yellow). >> builder fillNode: 43 withColor: (Color green). >> >> builder strokeNodes: [ :n | (n \ 2) = 1 ] withColor: (Color blue). >> builder strokeNode: 13 withColor: (Color black). >> >> builder strokeNodes: [ :n | (n \ 6) = 0 ] withWidth: 2. >> builder strokeNode: 3 withColor: (Color red). >> builder strokeNode: 3 withWidth: 3. >> >> "Using the #drawOn: message for compatibility with
ROMondrianViewBuilder"
>> view := ROView new. >> view @ RODraggable. >> builder drawOn: view. >> view open. > > And the resulting tree map @
https://dl.dropboxusercontent.com/u/6281855/updated-treemap.png
> > Now I am converting from z-ordering to nesting. Stay tuned ;) > > Cheers, > Roby > >> On Oct 7, 2013, at 7:33 PM, Alexandre Bergel <
alexandre.bergel@me.com> wrote:
>> >> Looks good to me. >> Maybe you could have in addition to >> DFTreeMapBuilder>>associations: >> something >> DFTreeMapBuilder>>parent: aBlockOrASymbol >> >> Also, something very important that I forgot to mention, we need a
method DFTreeMapBuilder>>drawOn: aROView
>> >> Like that, we should be able to have a treemap when using the
mondrian builder. Using your example, we should have exactly the same result if we do:
>> -=-=-=-=-=-=-=-=-=-=-=-= >> builder := DFTreeMapBuilder new. >> builder ... // your example here >> >> view := ROView new. >> builder drawOn: view. >> view open >> -=-=-=-=-=-=-=-=-=-=-=-= >> >> Cheers, >> Alexandre >> >> >>> On Oct 7, 2013, at 1:07 PM, "roberto.minelli@usi.ch" <
roberto.minelli@usi.ch> wrote:
>>> >>> Hi, >>> >>> I finished the first version of the new tree map builder for
Roassal.
>>> >>> You can find the source code in my SmalltalkHub package
'DevFlow-View'!
>>> >>> Gofer new >>> smalltalkhubUser: 'RobertoMinelli' project: 'DevFlow'; >>> package: 'DevFlow-View'; >>> load. >>> >>> Here's an example usage: >>> >>> builder := DFTreeMapBuilder new. >>> builder weightBlock: [ :el | el ]. >>> builder nodes: (1 to: 50). >>> builder associations: (builder nodes allButFirst collect: [:each
| (each // 2) -> each ]).
>>> >>> "Some optional configurations parameters" >>> colors := Color white mix: Color blue shades: (builder nodes
size).
>>> builder colorBlock: [ :el | colors at: el ]. >>> builder rootColor: ((Color red) alpha: 0.5). >>> builder inset: 5. >>> builder extent: 500@300. >>> builder origin: 10@30. >>> >>> builder draw. >>> >>> And the resulting tree map! >>> >>> [cid:EC2669CC-CA97-4B81-8B1B-B792FBE1C04F@mobile.usilu.net] >>> >>> Please tell me what do you think! >>> >>> The next steps are: >>> - Add customizable interactions >>> - Remove z-ordering and use proper nesting >>> - Eventually unroll the recursion in the layout algorithm >>> >>> Cheers, >>> Roberto >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> 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
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"
Hi Doru,
I just added options for shading (on nodes this time) so that you do not have to care about the colors explicitly.
Now we have the messages for: - #withShadesOnWeightFromColor:toColor: --> Applies the shading on the weight of the node - #withShadesOnNestingFromColor:toColor: --> Applies the shading on the nesting level of the node
What's the real difference between a LinearColorNormalizer and #mix:shades: I really like #mix:shades: :D
In a minute I will also provide what you said for the shaded frames: #withShadedFrames was an example on how to produce framed tree maps with a single message ;)
Cheers, Roby
On Oct 9, 2013, at 10:47 AM, Tudor Girba tudor@tudorgirba.com wrote:
Ok, I took a closer look and you already implemented almost what I said :).
So, let's take a look: withShadedFrames self inset: 1. self strokeAllNodesWithColorBlock: [ :el | Color darkGray darker adjustSaturation: (-0.03 * el depth) brightness: (el depth * 0.08). ].
This is a good start, but:
- Color darkGray should not be hardcoded
- The actual darkening strategy should not be hardcoded either
I would suggest to use a LinearColorNormalizer instead. This allows you to specify both the min and max color. What do you say?
Cheers, Doru
On Wed, Oct 9, 2013 at 10:11 AM, Tudor Girba tudor@tudorgirba.com wrote: Nice!
I just do not understand why colors has the same size as the nodes collection. It should have the same size as the max nesting level. What do I get wrong?
In any case, I think for shading we need also strategy that hides the implementation details (so, no explicit color creation). I think that we can just give a min and a max and then simply use a linear color normalizer internally. Of course, we also need a way to marry such an implicit strategy with the possibility of custom colors :). Proposals?
Doru
On Wed, Oct 9, 2013 at 10:02 AM, roberto.minelli@usi.ch roberto.minelli@usi.ch wrote: Sorry, DropBox messed up the image name. I updated the file ;)
On Oct 9, 2013, at 9:57 AM, Yuriy Tymchuk yuriy.tymchuk@me.com wrote:
404 on dropbox
On Oct 9, 2013, at 9:30 AM, roberto.minelli@usi.ch wrote:
Here is another way to visualize the nesting, with frames. It's enough to call #withShadedFrames. How cool is that?
Here's a sample visualization @ https://dl.dropboxusercontent.com/u/6281855/treemap-frames.png
And here's the script:
builder := DFTreeMapBuilder new. builder weightBlock: [ :el | el ]. builder nodes: (1 to: 100). builder nestingFromAssociations: (builder nodes allButFirst collect: [:each | (each // 2) -> each ]).
"Some optional configurations parameters" colors := (Color lightBlue) mix: Color blue shades: (builder nodes size). builder colorBlock: [ :el | colors at: el ]. builder rootColor: (Color red). builder extent: 521@312. builder origin: 20@20.
builder withShadedFrames.
builder draw.
Roby
On Oct 9, 2013, at 8:12 AM, "roberto.minelli@usi.ch" roberto.minelli@usi.ch wrote:
And yes, now the tree map builder does no longer use z-ordering to lay out the elements ;)
On Oct 8, 2013, at 12:51 PM, Alexandre Bergel alexandre.bergel@me.com wrote:
Ok, excellent!!!
Alexandre
Le 08-10-2013 à 6:44, "roberto.minelli@usi.ch" roberto.minelli@usi.ch a écrit :
Hi,
I made a couple of changes of the builder as per your suggestions. An updated usage script would be:
> builder := DFTreeMapBuilder new. > builder weightBlock: [ :el | el ]. > builder nodes: (1 to: 50). > builder nestingFromAssociations: (builder nodes allButFirst collect: [:each | (each // 2) -> each ]). > > "Some optional configurations parameters" > colors := Color green mix: Color blue shades: (builder nodes size). > builder colorBlock: [ :el | colors at: el ]. > builder rootColor: ((Color red) alpha: 0.5). > builder inset: 5. > builder extent: 300@400. > builder origin: 10@30. > > "Some node-specific customization" > builder fillNodes: [ :n | (n > 40) ] withColor: (Color white). > builder fillNode: 50 withColor: (Color yellow). > builder fillNode: 43 withColor: (Color green). > > builder strokeNodes: [ :n | (n \ 2) = 1 ] withColor: (Color blue). > builder strokeNode: 13 withColor: (Color black). > > builder strokeNodes: [ :n | (n \ 6) = 0 ] withWidth: 2. > builder strokeNode: 3 withColor: (Color red). > builder strokeNode: 3 withWidth: 3. > > "Using the #drawOn: message for compatibility with ROMondrianViewBuilder" > view := ROView new. > view @ RODraggable. > builder drawOn: view. > view open.
And the resulting tree map @ https://dl.dropboxusercontent.com/u/6281855/updated-treemap.png
Now I am converting from z-ordering to nesting. Stay tuned ;)
Cheers, Roby
> On Oct 7, 2013, at 7:33 PM, Alexandre Bergel alexandre.bergel@me.com wrote: > > Looks good to me. > Maybe you could have in addition to > DFTreeMapBuilder>>associations: > something > DFTreeMapBuilder>>parent: aBlockOrASymbol > > Also, something very important that I forgot to mention, we need a method DFTreeMapBuilder>>drawOn: aROView > > Like that, we should be able to have a treemap when using the mondrian builder. Using your example, we should have exactly the same result if we do: > -=-=-=-=-=-=-=-=-=-=-=-= > builder := DFTreeMapBuilder new. > builder ... // your example here > > view := ROView new. > builder drawOn: view. > view open > -=-=-=-=-=-=-=-=-=-=-=-= > > Cheers, > Alexandre > > >> On Oct 7, 2013, at 1:07 PM, "roberto.minelli@usi.ch" roberto.minelli@usi.ch wrote: >> >> Hi, >> >> I finished the first version of the new tree map builder for Roassal. >> >> You can find the source code in my SmalltalkHub package 'DevFlow-View'! >> >> Gofer new >> smalltalkhubUser: 'RobertoMinelli' project: 'DevFlow'; >> package: 'DevFlow-View'; >> load. >> >> Here's an example usage: >> >> builder := DFTreeMapBuilder new. >> builder weightBlock: [ :el | el ]. >> builder nodes: (1 to: 50). >> builder associations: (builder nodes allButFirst collect: [:each | (each // 2) -> each ]). >> >> "Some optional configurations parameters" >> colors := Color white mix: Color blue shades: (builder nodes size). >> builder colorBlock: [ :el | colors at: el ]. >> builder rootColor: ((Color red) alpha: 0.5). >> builder inset: 5. >> builder extent: 500@300. >> builder origin: 10@30. >> >> builder draw. >> >> And the resulting tree map! >> >> [cid:EC2669CC-CA97-4B81-8B1B-B792FBE1C04F@mobile.usilu.net] >> >> Please tell me what do you think! >> >> The next steps are: >> - Add customizable interactions >> - Remove z-ordering and use proper nesting >> - Eventually unroll the recursion in the layout algorithm >> >> Cheers, >> Roberto > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > 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
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"
-- 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
Now you can shade strokes with the message #withShadedFramesFromColor:toColor:. HoweverI kept the default shading with the message #withShadedFrames with hardcoded strategy & color.
Cheers, Roby
On Oct 9, 2013, at 11:28 AM, "roberto.minelli@usi.ch" roberto.minelli@usi.ch wrote:
Hi Doru,
I just added options for shading (on nodes this time) so that you do not have to care about the colors explicitly.
Now we have the messages for:
- #withShadesOnWeightFromColor:toColor: --> Applies the shading on the weight of the node
- #withShadesOnNestingFromColor:toColor: --> Applies the shading on the nesting level of the node
What's the real difference between a LinearColorNormalizer and #mix:shades: I really like #mix:shades: :D
In a minute I will also provide what you said for the shaded frames: #withShadedFrames was an example on how to produce framed tree maps with a single message ;)
Cheers, Roby
On Oct 9, 2013, at 10:47 AM, Tudor Girba tudor@tudorgirba.com wrote:
Ok, I took a closer look and you already implemented almost what I said :).
So, let's take a look: withShadedFrames self inset: 1. self strokeAllNodesWithColorBlock: [ :el | Color darkGray darker adjustSaturation: (-0.03 * el depth) brightness: (el depth * 0.08). ].
This is a good start, but:
- Color darkGray should not be hardcoded
- The actual darkening strategy should not be hardcoded either
I would suggest to use a LinearColorNormalizer instead. This allows you to specify both the min and max color. What do you say?
Cheers, Doru
On Wed, Oct 9, 2013 at 10:11 AM, Tudor Girba tudor@tudorgirba.com wrote: Nice!
I just do not understand why colors has the same size as the nodes collection. It should have the same size as the max nesting level. What do I get wrong?
In any case, I think for shading we need also strategy that hides the implementation details (so, no explicit color creation). I think that we can just give a min and a max and then simply use a linear color normalizer internally. Of course, we also need a way to marry such an implicit strategy with the possibility of custom colors :). Proposals?
Doru
On Wed, Oct 9, 2013 at 10:02 AM, roberto.minelli@usi.ch roberto.minelli@usi.ch wrote: Sorry, DropBox messed up the image name. I updated the file ;)
On Oct 9, 2013, at 9:57 AM, Yuriy Tymchuk yuriy.tymchuk@me.com wrote:
404 on dropbox
On Oct 9, 2013, at 9:30 AM, roberto.minelli@usi.ch wrote:
Here is another way to visualize the nesting, with frames. It's enough to call #withShadedFrames. How cool is that?
Here's a sample visualization @ https://dl.dropboxusercontent.com/u/6281855/treemap-frames.png
And here's the script:
builder := DFTreeMapBuilder new. builder weightBlock: [ :el | el ]. builder nodes: (1 to: 100). builder nestingFromAssociations: (builder nodes allButFirst collect: [:each | (each // 2) -> each ]).
"Some optional configurations parameters" colors := (Color lightBlue) mix: Color blue shades: (builder nodes size). builder colorBlock: [ :el | colors at: el ]. builder rootColor: (Color red). builder extent: 521@312. builder origin: 20@20.
builder withShadedFrames.
builder draw.
Roby
On Oct 9, 2013, at 8:12 AM, "roberto.minelli@usi.ch" roberto.minelli@usi.ch wrote:
And yes, now the tree map builder does no longer use z-ordering to lay out the elements ;)
On Oct 8, 2013, at 12:51 PM, Alexandre Bergel alexandre.bergel@me.com wrote:
Ok, excellent!!!
Alexandre
> Le 08-10-2013 à 6:44, "roberto.minelli@usi.ch" roberto.minelli@usi.ch a écrit : > > Hi, > > I made a couple of changes of the builder as per your suggestions. An updated usage script would be: > >> builder := DFTreeMapBuilder new. >> builder weightBlock: [ :el | el ]. >> builder nodes: (1 to: 50). >> builder nestingFromAssociations: (builder nodes allButFirst collect: [:each | (each // 2) -> each ]). >> >> "Some optional configurations parameters" >> colors := Color green mix: Color blue shades: (builder nodes size). >> builder colorBlock: [ :el | colors at: el ]. >> builder rootColor: ((Color red) alpha: 0.5). >> builder inset: 5. >> builder extent: 300@400. >> builder origin: 10@30. >> >> "Some node-specific customization" >> builder fillNodes: [ :n | (n > 40) ] withColor: (Color white). >> builder fillNode: 50 withColor: (Color yellow). >> builder fillNode: 43 withColor: (Color green). >> >> builder strokeNodes: [ :n | (n \ 2) = 1 ] withColor: (Color blue). >> builder strokeNode: 13 withColor: (Color black). >> >> builder strokeNodes: [ :n | (n \ 6) = 0 ] withWidth: 2. >> builder strokeNode: 3 withColor: (Color red). >> builder strokeNode: 3 withWidth: 3. >> >> "Using the #drawOn: message for compatibility with ROMondrianViewBuilder" >> view := ROView new. >> view @ RODraggable. >> builder drawOn: view. >> view open. > > And the resulting tree map @ https://dl.dropboxusercontent.com/u/6281855/updated-treemap.png > > Now I am converting from z-ordering to nesting. Stay tuned ;) > > Cheers, > Roby > >> On Oct 7, 2013, at 7:33 PM, Alexandre Bergel alexandre.bergel@me.com wrote: >> >> Looks good to me. >> Maybe you could have in addition to >> DFTreeMapBuilder>>associations: >> something >> DFTreeMapBuilder>>parent: aBlockOrASymbol >> >> Also, something very important that I forgot to mention, we need a method DFTreeMapBuilder>>drawOn: aROView >> >> Like that, we should be able to have a treemap when using the mondrian builder. Using your example, we should have exactly the same result if we do: >> -=-=-=-=-=-=-=-=-=-=-=-= >> builder := DFTreeMapBuilder new. >> builder ... // your example here >> >> view := ROView new. >> builder drawOn: view. >> view open >> -=-=-=-=-=-=-=-=-=-=-=-= >> >> Cheers, >> Alexandre >> >> >>> On Oct 7, 2013, at 1:07 PM, "roberto.minelli@usi.ch" roberto.minelli@usi.ch wrote: >>> >>> Hi, >>> >>> I finished the first version of the new tree map builder for Roassal. >>> >>> You can find the source code in my SmalltalkHub package 'DevFlow-View'! >>> >>> Gofer new >>> smalltalkhubUser: 'RobertoMinelli' project: 'DevFlow'; >>> package: 'DevFlow-View'; >>> load. >>> >>> Here's an example usage: >>> >>> builder := DFTreeMapBuilder new. >>> builder weightBlock: [ :el | el ]. >>> builder nodes: (1 to: 50). >>> builder associations: (builder nodes allButFirst collect: [:each | (each // 2) -> each ]). >>> >>> "Some optional configurations parameters" >>> colors := Color white mix: Color blue shades: (builder nodes size). >>> builder colorBlock: [ :el | colors at: el ]. >>> builder rootColor: ((Color red) alpha: 0.5). >>> builder inset: 5. >>> builder extent: 500@300. >>> builder origin: 10@30. >>> >>> builder draw. >>> >>> And the resulting tree map! >>> >>> [cid:EC2669CC-CA97-4B81-8B1B-B792FBE1C04F@mobile.usilu.net] >>> >>> Please tell me what do you think! >>> >>> The next steps are: >>> - Add customizable interactions >>> - Remove z-ordering and use proper nesting >>> - Eventually unroll the recursion in the layout algorithm >>> >>> Cheers, >>> Roberto >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> 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
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"
-- 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
Nice! I want this integrated in Roassal, or at least in Moose. Alex?
About LinearColorNormalizer vs. mix:shades:.
LinearColorNormalizer is better in that it does not create the actual colors. Imagine that you have 2 nodes: one with weight 1 and one with weight 10000. Using mix:shades: you will generate 10000 shades. With LinearColorNormalizer you will generate exactly 2.
Doru
On Wed, Oct 9, 2013 at 11:43 AM, roberto.minelli@usi.ch < roberto.minelli@usi.ch> wrote:
Now you can shade strokes with the message #withShadedFramesFromColor:toColor:. HoweverI kept the default shading with the message #withShadedFrames with hardcoded strategy & color.
Cheers, Roby
On Oct 9, 2013, at 11:28 AM, "roberto.minelli@usi.ch" < roberto.minelli@usi.ch> wrote:
Hi Doru,
I just added options for shading (on nodes this time) so that you do not
have to care about the colors explicitly.
Now we have the messages for:
- #withShadesOnWeightFromColor:toColor: --> Applies the shading on the
weight of the node
- #withShadesOnNestingFromColor:toColor: --> Applies the shading on the
nesting level of the node
What's the real difference between a LinearColorNormalizer and
#mix:shades: I really like #mix:shades: :D
In a minute I will also provide what you said for the shaded frames:
#withShadedFrames was an example on how to produce framed tree maps with a single message ;)
Cheers, Roby
On Oct 9, 2013, at 10:47 AM, Tudor Girba tudor@tudorgirba.com wrote:
Ok, I took a closer look and you already implemented almost what I said
:).
So, let's take a look: withShadedFrames self inset: 1. self strokeAllNodesWithColorBlock: [ :el | Color darkGray darker adjustSaturation: (-0.03 * el depth)
brightness: (el depth * 0.08).
].This is a good start, but:
- Color darkGray should not be hardcoded
- The actual darkening strategy should not be hardcoded either
I would suggest to use a LinearColorNormalizer instead. This allows you
to specify both the min and max color. What do you say?
Cheers, Doru
On Wed, Oct 9, 2013 at 10:11 AM, Tudor Girba tudor@tudorgirba.com
wrote:
Nice!
I just do not understand why colors has the same size as the nodes
collection. It should have the same size as the max nesting level. What do I get wrong?
In any case, I think for shading we need also strategy that hides the
implementation details (so, no explicit color creation). I think that we can just give a min and a max and then simply use a linear color normalizer internally. Of course, we also need a way to marry such an implicit strategy with the possibility of custom colors :). Proposals?
Doru
On Wed, Oct 9, 2013 at 10:02 AM, roberto.minelli@usi.ch <
roberto.minelli@usi.ch> wrote:
Sorry, DropBox messed up the image name. I updated the file ;)
On Oct 9, 2013, at 9:57 AM, Yuriy Tymchuk yuriy.tymchuk@me.com wrote:
404 on dropbox
On Oct 9, 2013, at 9:30 AM, roberto.minelli@usi.ch wrote:
Here is another way to visualize the nesting, with frames. It's
enough to call #withShadedFrames. How cool is that?
Here's a sample visualization @
https://dl.dropboxusercontent.com/u/6281855/treemap-frames.png
And here's the script:
=-=-=--=-=-=-=-=-=--=-=-=-=-=-=--=-=-=-=-=-=--=-=-=-=-=-=--=-=-=-=-=-=--=-=-=-=-=-=--=-=-=-=-=-=--=-=-=-
builder := DFTreeMapBuilder new. builder weightBlock: [ :el | el ]. builder nodes: (1 to: 100). builder nestingFromAssociations: (builder nodes allButFirst collect:
[:each | (each // 2) -> each ]).
"Some optional configurations parameters" colors := (Color lightBlue) mix: Color blue shades: (builder nodes
size).
builder colorBlock: [ :el | colors at: el ]. builder rootColor: (Color red). builder extent: 521@312. builder origin: 20@20.
builder withShadedFrames.
builder draw.
=-=-=--=-=-=-=-=-=--=-=-=-=-=-=--=-=-=-=-=-=--=-=-=-=-=-=--=-=-=-=-=-=--=-=-=-=-=-=--=-=-=-=-=-=--=-=-=-
Roby
On Oct 9, 2013, at 8:12 AM, "roberto.minelli@usi.ch" <
roberto.minelli@usi.ch>
wrote:
And yes, now the tree map builder does no longer use z-ordering to
lay out the elements ;)
On Oct 8, 2013, at 12:51 PM, Alexandre Bergel <
alexandre.bergel@me.com> wrote:
> Ok, excellent!!! > > Alexandre > >> Le 08-10-2013 à 6:44, "roberto.minelli@usi.ch" <
roberto.minelli@usi.ch> a écrit :
>> >> Hi, >> >> I made a couple of changes of the builder as per your suggestions.
An updated usage script would be:
>> >>> builder := DFTreeMapBuilder new. >>> builder weightBlock: [ :el | el ]. >>> builder nodes: (1 to: 50). >>> builder nestingFromAssociations: (builder nodes allButFirst
collect: [:each | (each // 2) -> each ]).
>>> >>> "Some optional configurations parameters" >>> colors := Color green mix: Color blue shades: (builder nodes
size).
>>> builder colorBlock: [ :el | colors at: el ]. >>> builder rootColor: ((Color red) alpha: 0.5). >>> builder inset: 5. >>> builder extent: 300@400. >>> builder origin: 10@30. >>> >>> "Some node-specific customization" >>> builder fillNodes: [ :n | (n > 40) ] withColor: (Color white). >>> builder fillNode: 50 withColor: (Color yellow). >>> builder fillNode: 43 withColor: (Color green). >>> >>> builder strokeNodes: [ :n | (n \ 2) = 1 ] withColor: (Color
blue).
>>> builder strokeNode: 13 withColor: (Color black). >>> >>> builder strokeNodes: [ :n | (n \ 6) = 0 ] withWidth: 2. >>> builder strokeNode: 3 withColor: (Color red). >>> builder strokeNode: 3 withWidth: 3. >>> >>> "Using the #drawOn: message for compatibility with
ROMondrianViewBuilder"
>>> view := ROView new. >>> view @ RODraggable. >>> builder drawOn: view. >>> view open. >> >> And the resulting tree map @
https://dl.dropboxusercontent.com/u/6281855/updated-treemap.png
>> >> Now I am converting from z-ordering to nesting. Stay tuned ;) >> >> Cheers, >> Roby >> >>> On Oct 7, 2013, at 7:33 PM, Alexandre Bergel <
alexandre.bergel@me.com> wrote:
>>> >>> Looks good to me. >>> Maybe you could have in addition to >>> DFTreeMapBuilder>>associations: >>> something >>> DFTreeMapBuilder>>parent: aBlockOrASymbol >>> >>> Also, something very important that I forgot to mention, we need
a method DFTreeMapBuilder>>drawOn: aROView
>>> >>> Like that, we should be able to have a treemap when using the
mondrian builder. Using your example, we should have exactly the same result if we do:
>>> -=-=-=-=-=-=-=-=-=-=-=-= >>> builder := DFTreeMapBuilder new. >>> builder ... // your example here >>> >>> view := ROView new. >>> builder drawOn: view. >>> view open >>> -=-=-=-=-=-=-=-=-=-=-=-= >>> >>> Cheers, >>> Alexandre >>> >>> >>>> On Oct 7, 2013, at 1:07 PM, "roberto.minelli@usi.ch" <
roberto.minelli@usi.ch> wrote:
>>>> >>>> Hi, >>>> >>>> I finished the first version of the new tree map builder for
Roassal.
>>>> >>>> You can find the source code in my SmalltalkHub package
'DevFlow-View'!
>>>> >>>> Gofer new >>>> smalltalkhubUser: 'RobertoMinelli' project: 'DevFlow'; >>>> package: 'DevFlow-View'; >>>> load. >>>> >>>> Here's an example usage: >>>> >>>> builder := DFTreeMapBuilder new. >>>> builder weightBlock: [ :el | el ]. >>>> builder nodes: (1 to: 50). >>>> builder associations: (builder nodes allButFirst collect: [:each
| (each // 2) -> each ]).
>>>> >>>> "Some optional configurations parameters" >>>> colors := Color white mix: Color blue shades: (builder nodes
size).
>>>> builder colorBlock: [ :el | colors at: el ]. >>>> builder rootColor: ((Color red) alpha: 0.5). >>>> builder inset: 5. >>>> builder extent: 500@300. >>>> builder origin: 10@30. >>>> >>>> builder draw. >>>> >>>> And the resulting tree map! >>>> >>>> [cid:EC2669CC-CA97-4B81-8B1B-B792FBE1C04F@mobile.usilu.net] >>>> >>>> Please tell me what do you think! >>>> >>>> The next steps are: >>>> - Add customizable interactions >>>> - Remove z-ordering and use proper nesting >>>> - Eventually unroll the recursion in the layout algorithm >>>> >>>> Cheers, >>>> Roberto >>> >>> -- >>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>> 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
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"
-- 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
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Yes, this should be integrated in Roassal. I am all for. But first, the code has to be functional. Currently I have an error.
Roberto, is your code ready you feel? Can you have a class DFTreeMapExample with a couple of examples? You may want to follow the convention of ROExample.
By the way, how do you want it to be integrated in Roassal. Is it okay if I rename your class with RORectangleTreeMap, ROTreeMapBuilder ? Is DevFlow the name of the project you are working on?
Alexandre
On Oct 9, 2013, at 4:31 PM, Tudor Girba tudor@tudorgirba.com wrote:
Nice! I want this integrated in Roassal, or at least in Moose. Alex?
About LinearColorNormalizer vs. mix:shades:.
LinearColorNormalizer is better in that it does not create the actual colors. Imagine that you have 2 nodes: one with weight 1 and one with weight 10000. Using mix:shades: you will generate 10000 shades. With LinearColorNormalizer you will generate exactly 2.
Doru
On Wed, Oct 9, 2013 at 11:43 AM, roberto.minelli@usi.ch roberto.minelli@usi.ch wrote: Now you can shade strokes with the message #withShadedFramesFromColor:toColor:. HoweverI kept the default shading with the message #withShadedFrames with hardcoded strategy & color.
Cheers, Roby
On Oct 9, 2013, at 11:28 AM, "roberto.minelli@usi.ch" roberto.minelli@usi.ch wrote:
Hi Doru,
I just added options for shading (on nodes this time) so that you do not have to care about the colors explicitly.
Now we have the messages for:
- #withShadesOnWeightFromColor:toColor: --> Applies the shading on the weight of the node
- #withShadesOnNestingFromColor:toColor: --> Applies the shading on the nesting level of the node
What's the real difference between a LinearColorNormalizer and #mix:shades: I really like #mix:shades: :D
In a minute I will also provide what you said for the shaded frames: #withShadedFrames was an example on how to produce framed tree maps with a single message ;)
Cheers, Roby
On Oct 9, 2013, at 10:47 AM, Tudor Girba tudor@tudorgirba.com wrote:
Ok, I took a closer look and you already implemented almost what I said :).
So, let's take a look: withShadedFrames self inset: 1. self strokeAllNodesWithColorBlock: [ :el | Color darkGray darker adjustSaturation: (-0.03 * el depth) brightness: (el depth * 0.08). ].
This is a good start, but:
- Color darkGray should not be hardcoded
- The actual darkening strategy should not be hardcoded either
I would suggest to use a LinearColorNormalizer instead. This allows you to specify both the min and max color. What do you say?
Cheers, Doru
On Wed, Oct 9, 2013 at 10:11 AM, Tudor Girba tudor@tudorgirba.com wrote: Nice!
I just do not understand why colors has the same size as the nodes collection. It should have the same size as the max nesting level. What do I get wrong?
In any case, I think for shading we need also strategy that hides the implementation details (so, no explicit color creation). I think that we can just give a min and a max and then simply use a linear color normalizer internally. Of course, we also need a way to marry such an implicit strategy with the possibility of custom colors :). Proposals?
Doru
On Wed, Oct 9, 2013 at 10:02 AM, roberto.minelli@usi.ch roberto.minelli@usi.ch wrote: Sorry, DropBox messed up the image name. I updated the file ;)
On Oct 9, 2013, at 9:57 AM, Yuriy Tymchuk yuriy.tymchuk@me.com wrote:
404 on dropbox
On Oct 9, 2013, at 9:30 AM, roberto.minelli@usi.ch wrote:
Here is another way to visualize the nesting, with frames. It's enough to call #withShadedFrames. How cool is that?
Here's a sample visualization @ https://dl.dropboxusercontent.com/u/6281855/treemap-frames.png
And here's the script:
builder := DFTreeMapBuilder new. builder weightBlock: [ :el | el ]. builder nodes: (1 to: 100). builder nestingFromAssociations: (builder nodes allButFirst collect: [:each | (each // 2) -> each ]).
"Some optional configurations parameters" colors := (Color lightBlue) mix: Color blue shades: (builder nodes size). builder colorBlock: [ :el | colors at: el ]. builder rootColor: (Color red). builder extent: 521@312. builder origin: 20@20.
builder withShadedFrames.
builder draw.
Roby
On Oct 9, 2013, at 8:12 AM, "roberto.minelli@usi.ch" roberto.minelli@usi.ch wrote:
And yes, now the tree map builder does no longer use z-ordering to lay out the elements ;)
On Oct 8, 2013, at 12:51 PM, Alexandre Bergel alexandre.bergel@me.com wrote:
> Ok, excellent!!! > > Alexandre > >> Le 08-10-2013 à 6:44, "roberto.minelli@usi.ch" roberto.minelli@usi.ch a écrit : >> >> Hi, >> >> I made a couple of changes of the builder as per your suggestions. An updated usage script would be: >> >>> builder := DFTreeMapBuilder new. >>> builder weightBlock: [ :el | el ]. >>> builder nodes: (1 to: 50). >>> builder nestingFromAssociations: (builder nodes allButFirst collect: [:each | (each // 2) -> each ]). >>> >>> "Some optional configurations parameters" >>> colors := Color green mix: Color blue shades: (builder nodes size). >>> builder colorBlock: [ :el | colors at: el ]. >>> builder rootColor: ((Color red) alpha: 0.5). >>> builder inset: 5. >>> builder extent: 300@400. >>> builder origin: 10@30. >>> >>> "Some node-specific customization" >>> builder fillNodes: [ :n | (n > 40) ] withColor: (Color white). >>> builder fillNode: 50 withColor: (Color yellow). >>> builder fillNode: 43 withColor: (Color green). >>> >>> builder strokeNodes: [ :n | (n \ 2) = 1 ] withColor: (Color blue). >>> builder strokeNode: 13 withColor: (Color black). >>> >>> builder strokeNodes: [ :n | (n \ 6) = 0 ] withWidth: 2. >>> builder strokeNode: 3 withColor: (Color red). >>> builder strokeNode: 3 withWidth: 3. >>> >>> "Using the #drawOn: message for compatibility with ROMondrianViewBuilder" >>> view := ROView new. >>> view @ RODraggable. >>> builder drawOn: view. >>> view open. >> >> And the resulting tree map @ https://dl.dropboxusercontent.com/u/6281855/updated-treemap.png >> >> Now I am converting from z-ordering to nesting. Stay tuned ;) >> >> Cheers, >> Roby >> >>> On Oct 7, 2013, at 7:33 PM, Alexandre Bergel alexandre.bergel@me.com wrote: >>> >>> Looks good to me. >>> Maybe you could have in addition to >>> DFTreeMapBuilder>>associations: >>> something >>> DFTreeMapBuilder>>parent: aBlockOrASymbol >>> >>> Also, something very important that I forgot to mention, we need a method DFTreeMapBuilder>>drawOn: aROView >>> >>> Like that, we should be able to have a treemap when using the mondrian builder. Using your example, we should have exactly the same result if we do: >>> -=-=-=-=-=-=-=-=-=-=-=-= >>> builder := DFTreeMapBuilder new. >>> builder ... // your example here >>> >>> view := ROView new. >>> builder drawOn: view. >>> view open >>> -=-=-=-=-=-=-=-=-=-=-=-= >>> >>> Cheers, >>> Alexandre >>> >>> >>>> On Oct 7, 2013, at 1:07 PM, "roberto.minelli@usi.ch" roberto.minelli@usi.ch wrote: >>>> >>>> Hi, >>>> >>>> I finished the first version of the new tree map builder for Roassal. >>>> >>>> You can find the source code in my SmalltalkHub package 'DevFlow-View'! >>>> >>>> Gofer new >>>> smalltalkhubUser: 'RobertoMinelli' project: 'DevFlow'; >>>> package: 'DevFlow-View'; >>>> load. >>>> >>>> Here's an example usage: >>>> >>>> builder := DFTreeMapBuilder new. >>>> builder weightBlock: [ :el | el ]. >>>> builder nodes: (1 to: 50). >>>> builder associations: (builder nodes allButFirst collect: [:each | (each // 2) -> each ]). >>>> >>>> "Some optional configurations parameters" >>>> colors := Color white mix: Color blue shades: (builder nodes size). >>>> builder colorBlock: [ :el | colors at: el ]. >>>> builder rootColor: ((Color red) alpha: 0.5). >>>> builder inset: 5. >>>> builder extent: 500@300. >>>> builder origin: 10@30. >>>> >>>> builder draw. >>>> >>>> And the resulting tree map! >>>> >>>> [cid:EC2669CC-CA97-4B81-8B1B-B792FBE1C04F@mobile.usilu.net] >>>> >>>> Please tell me what do you think! >>>> >>>> The next steps are: >>>> - Add customizable interactions >>>> - Remove z-ordering and use proper nesting >>>> - Eventually unroll the recursion in the layout algorithm >>>> >>>> Cheers, >>>> Roberto >>> >>> -- >>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>> 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
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"
-- 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
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
On Oct 9, 2013, at 9:31 PM, Tudor Girba tudor@tudorgirba.com wrote:
Nice! I want this integrated in Roassal, or at least in Moose. Alex?
Would be cool!
About LinearColorNormalizer vs. mix:shades:.
LinearColorNormalizer is better in that it does not create the actual colors. Imagine that you have 2 nodes: one with weight 1 and one with weight 10000. Using mix:shades: you will generate 10000 shades. With LinearColorNormalizer you will generate exactly 2.
Oh, I see. I will probably switch to the color normalizer then!
Doru
On Wed, Oct 9, 2013 at 11:43 AM, roberto.minelli@usi.ch roberto.minelli@usi.ch wrote: Now you can shade strokes with the message #withShadedFramesFromColor:toColor:. HoweverI kept the default shading with the message #withShadedFrames with hardcoded strategy & color.
Cheers, Roby
On Oct 9, 2013, at 11:28 AM, "roberto.minelli@usi.ch" roberto.minelli@usi.ch wrote:
Hi Doru,
I just added options for shading (on nodes this time) so that you do not have to care about the colors explicitly.
Now we have the messages for:
- #withShadesOnWeightFromColor:toColor: --> Applies the shading on the weight of the node
- #withShadesOnNestingFromColor:toColor: --> Applies the shading on the nesting level of the node
What's the real difference between a LinearColorNormalizer and #mix:shades: I really like #mix:shades: :D
In a minute I will also provide what you said for the shaded frames: #withShadedFrames was an example on how to produce framed tree maps with a single message ;)
Cheers, Roby
On Oct 9, 2013, at 10:47 AM, Tudor Girba tudor@tudorgirba.com wrote:
Ok, I took a closer look and you already implemented almost what I said :).
So, let's take a look: withShadedFrames self inset: 1. self strokeAllNodesWithColorBlock: [ :el | Color darkGray darker adjustSaturation: (-0.03 * el depth) brightness: (el depth * 0.08). ].
This is a good start, but:
- Color darkGray should not be hardcoded
- The actual darkening strategy should not be hardcoded either
I would suggest to use a LinearColorNormalizer instead. This allows you to specify both the min and max color. What do you say?
Cheers, Doru
On Wed, Oct 9, 2013 at 10:11 AM, Tudor Girba tudor@tudorgirba.com wrote: Nice!
I just do not understand why colors has the same size as the nodes collection. It should have the same size as the max nesting level. What do I get wrong?
In any case, I think for shading we need also strategy that hides the implementation details (so, no explicit color creation). I think that we can just give a min and a max and then simply use a linear color normalizer internally. Of course, we also need a way to marry such an implicit strategy with the possibility of custom colors :). Proposals?
Doru
On Wed, Oct 9, 2013 at 10:02 AM, roberto.minelli@usi.ch roberto.minelli@usi.ch wrote: Sorry, DropBox messed up the image name. I updated the file ;)
On Oct 9, 2013, at 9:57 AM, Yuriy Tymchuk yuriy.tymchuk@me.com wrote:
404 on dropbox
On Oct 9, 2013, at 9:30 AM, roberto.minelli@usi.ch wrote:
Here is another way to visualize the nesting, with frames. It's enough to call #withShadedFrames. How cool is that?
Here's a sample visualization @ https://dl.dropboxusercontent.com/u/6281855/treemap-frames.png
And here's the script:
builder := DFTreeMapBuilder new. builder weightBlock: [ :el | el ]. builder nodes: (1 to: 100). builder nestingFromAssociations: (builder nodes allButFirst collect: [:each | (each // 2) -> each ]).
"Some optional configurations parameters" colors := (Color lightBlue) mix: Color blue shades: (builder nodes size). builder colorBlock: [ :el | colors at: el ]. builder rootColor: (Color red). builder extent: 521@312. builder origin: 20@20.
builder withShadedFrames.
builder draw.
Roby
On Oct 9, 2013, at 8:12 AM, "roberto.minelli@usi.ch" roberto.minelli@usi.ch wrote:
And yes, now the tree map builder does no longer use z-ordering to lay out the elements ;)
On Oct 8, 2013, at 12:51 PM, Alexandre Bergel alexandre.bergel@me.com wrote:
> Ok, excellent!!! > > Alexandre > >> Le 08-10-2013 à 6:44, "roberto.minelli@usi.ch" roberto.minelli@usi.ch a écrit : >> >> Hi, >> >> I made a couple of changes of the builder as per your suggestions. An updated usage script would be: >> >>> builder := DFTreeMapBuilder new. >>> builder weightBlock: [ :el | el ]. >>> builder nodes: (1 to: 50). >>> builder nestingFromAssociations: (builder nodes allButFirst collect: [:each | (each // 2) -> each ]). >>> >>> "Some optional configurations parameters" >>> colors := Color green mix: Color blue shades: (builder nodes size). >>> builder colorBlock: [ :el | colors at: el ]. >>> builder rootColor: ((Color red) alpha: 0.5). >>> builder inset: 5. >>> builder extent: 300@400. >>> builder origin: 10@30. >>> >>> "Some node-specific customization" >>> builder fillNodes: [ :n | (n > 40) ] withColor: (Color white). >>> builder fillNode: 50 withColor: (Color yellow). >>> builder fillNode: 43 withColor: (Color green). >>> >>> builder strokeNodes: [ :n | (n \ 2) = 1 ] withColor: (Color blue). >>> builder strokeNode: 13 withColor: (Color black). >>> >>> builder strokeNodes: [ :n | (n \ 6) = 0 ] withWidth: 2. >>> builder strokeNode: 3 withColor: (Color red). >>> builder strokeNode: 3 withWidth: 3. >>> >>> "Using the #drawOn: message for compatibility with ROMondrianViewBuilder" >>> view := ROView new. >>> view @ RODraggable. >>> builder drawOn: view. >>> view open. >> >> And the resulting tree map @ https://dl.dropboxusercontent.com/u/6281855/updated-treemap.png >> >> Now I am converting from z-ordering to nesting. Stay tuned ;) >> >> Cheers, >> Roby >> >>> On Oct 7, 2013, at 7:33 PM, Alexandre Bergel alexandre.bergel@me.com wrote: >>> >>> Looks good to me. >>> Maybe you could have in addition to >>> DFTreeMapBuilder>>associations: >>> something >>> DFTreeMapBuilder>>parent: aBlockOrASymbol >>> >>> Also, something very important that I forgot to mention, we need a method DFTreeMapBuilder>>drawOn: aROView >>> >>> Like that, we should be able to have a treemap when using the mondrian builder. Using your example, we should have exactly the same result if we do: >>> -=-=-=-=-=-=-=-=-=-=-=-= >>> builder := DFTreeMapBuilder new. >>> builder ... // your example here >>> >>> view := ROView new. >>> builder drawOn: view. >>> view open >>> -=-=-=-=-=-=-=-=-=-=-=-= >>> >>> Cheers, >>> Alexandre >>> >>> >>>> On Oct 7, 2013, at 1:07 PM, "roberto.minelli@usi.ch" roberto.minelli@usi.ch wrote: >>>> >>>> Hi, >>>> >>>> I finished the first version of the new tree map builder for Roassal. >>>> >>>> You can find the source code in my SmalltalkHub package 'DevFlow-View'! >>>> >>>> Gofer new >>>> smalltalkhubUser: 'RobertoMinelli' project: 'DevFlow'; >>>> package: 'DevFlow-View'; >>>> load. >>>> >>>> Here's an example usage: >>>> >>>> builder := DFTreeMapBuilder new. >>>> builder weightBlock: [ :el | el ]. >>>> builder nodes: (1 to: 50). >>>> builder associations: (builder nodes allButFirst collect: [:each | (each // 2) -> each ]). >>>> >>>> "Some optional configurations parameters" >>>> colors := Color white mix: Color blue shades: (builder nodes size). >>>> builder colorBlock: [ :el | colors at: el ]. >>>> builder rootColor: ((Color red) alpha: 0.5). >>>> builder inset: 5. >>>> builder extent: 500@300. >>>> builder origin: 10@30. >>>> >>>> builder draw. >>>> >>>> And the resulting tree map! >>>> >>>> [cid:EC2669CC-CA97-4B81-8B1B-B792FBE1C04F@mobile.usilu.net] >>>> >>>> Please tell me what do you think! >>>> >>>> The next steps are: >>>> - Add customizable interactions >>>> - Remove z-ordering and use proper nesting >>>> - Eventually unroll the recursion in the layout algorithm >>>> >>>> Cheers, >>>> Roberto >>> >>> -- >>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>> 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
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"
-- 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
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
Hi,
I renamed all the classes which compose the tree map builder to RO* and they are ready for prime time (i.e., integration in Roassal or Moose).
In addition I provided a ROTreeMapBuilderExample with 10-ish examples on how to use the builder. I should comment the code, but I will do that tomorrow ;) I also committed a specialization of the ROBorder, a ROInnerBorder. As the class name says, it creates the border within the element's shape (i.e., better when lay outing). It's not fully functional, but I already tried out on my tree map and most of the times is ok ;)
Waiting for your feedback and comments.
P.s.: Why if a ROLine is filled with a translucent color its begin and end points are shaded-ish? Here's a screenshot @ https://dl.dropboxusercontent.com/u/6281855/gradient-begin-end.png
Cheers, Roby
On Oct 10, 2013, at 8:26 AM, roberto.minelli@usi.ch wrote:
On Oct 9, 2013, at 9:31 PM, Tudor Girba tudor@tudorgirba.com wrote:
Nice! I want this integrated in Roassal, or at least in Moose. Alex?
Would be cool!
About LinearColorNormalizer vs. mix:shades:.
LinearColorNormalizer is better in that it does not create the actual colors. Imagine that you have 2 nodes: one with weight 1 and one with weight 10000. Using mix:shades: you will generate 10000 shades. With LinearColorNormalizer you will generate exactly 2.
Oh, I see. I will probably switch to the color normalizer then!
Doru
On Wed, Oct 9, 2013 at 11:43 AM, roberto.minelli@usi.ch roberto.minelli@usi.ch wrote: Now you can shade strokes with the message #withShadedFramesFromColor:toColor:. HoweverI kept the default shading with the message #withShadedFrames with hardcoded strategy & color.
Cheers, Roby
On Oct 9, 2013, at 11:28 AM, "roberto.minelli@usi.ch" roberto.minelli@usi.ch wrote:
Hi Doru,
I just added options for shading (on nodes this time) so that you do not have to care about the colors explicitly.
Now we have the messages for:
- #withShadesOnWeightFromColor:toColor: --> Applies the shading on the weight of the node
- #withShadesOnNestingFromColor:toColor: --> Applies the shading on the nesting level of the node
What's the real difference between a LinearColorNormalizer and #mix:shades: I really like #mix:shades: :D
In a minute I will also provide what you said for the shaded frames: #withShadedFrames was an example on how to produce framed tree maps with a single message ;)
Cheers, Roby
On Oct 9, 2013, at 10:47 AM, Tudor Girba tudor@tudorgirba.com wrote:
Ok, I took a closer look and you already implemented almost what I said :).
So, let's take a look: withShadedFrames self inset: 1. self strokeAllNodesWithColorBlock: [ :el | Color darkGray darker adjustSaturation: (-0.03 * el depth) brightness: (el depth * 0.08). ].
This is a good start, but:
- Color darkGray should not be hardcoded
- The actual darkening strategy should not be hardcoded either
I would suggest to use a LinearColorNormalizer instead. This allows you to specify both the min and max color. What do you say?
Cheers, Doru
On Wed, Oct 9, 2013 at 10:11 AM, Tudor Girba tudor@tudorgirba.com wrote: Nice!
I just do not understand why colors has the same size as the nodes collection. It should have the same size as the max nesting level. What do I get wrong?
In any case, I think for shading we need also strategy that hides the implementation details (so, no explicit color creation). I think that we can just give a min and a max and then simply use a linear color normalizer internally. Of course, we also need a way to marry such an implicit strategy with the possibility of custom colors :). Proposals?
Doru
On Wed, Oct 9, 2013 at 10:02 AM, roberto.minelli@usi.ch roberto.minelli@usi.ch wrote: Sorry, DropBox messed up the image name. I updated the file ;)
On Oct 9, 2013, at 9:57 AM, Yuriy Tymchuk yuriy.tymchuk@me.com wrote:
404 on dropbox
On Oct 9, 2013, at 9:30 AM, roberto.minelli@usi.ch wrote:
Here is another way to visualize the nesting, with frames. It's enough to call #withShadedFrames. How cool is that?
Here's a sample visualization @ https://dl.dropboxusercontent.com/u/6281855/treemap-frames.png
And here's the script:
builder := DFTreeMapBuilder new. builder weightBlock: [ :el | el ]. builder nodes: (1 to: 100). builder nestingFromAssociations: (builder nodes allButFirst collect: [:each | (each // 2) -> each ]).
"Some optional configurations parameters" colors := (Color lightBlue) mix: Color blue shades: (builder nodes size). builder colorBlock: [ :el | colors at: el ]. builder rootColor: (Color red). builder extent: 521@312. builder origin: 20@20.
builder withShadedFrames.
builder draw.
Roby
On Oct 9, 2013, at 8:12 AM, "roberto.minelli@usi.ch" roberto.minelli@usi.ch wrote:
> And yes, now the tree map builder does no longer use z-ordering to lay out the elements ;) > > On Oct 8, 2013, at 12:51 PM, Alexandre Bergel alexandre.bergel@me.com wrote: > >> Ok, excellent!!! >> >> Alexandre >> >>> Le 08-10-2013 à 6:44, "roberto.minelli@usi.ch" roberto.minelli@usi.ch a écrit : >>> >>> Hi, >>> >>> I made a couple of changes of the builder as per your suggestions. An updated usage script would be: >>> >>>> builder := DFTreeMapBuilder new. >>>> builder weightBlock: [ :el | el ]. >>>> builder nodes: (1 to: 50). >>>> builder nestingFromAssociations: (builder nodes allButFirst collect: [:each | (each // 2) -> each ]). >>>> >>>> "Some optional configurations parameters" >>>> colors := Color green mix: Color blue shades: (builder nodes size). >>>> builder colorBlock: [ :el | colors at: el ]. >>>> builder rootColor: ((Color red) alpha: 0.5). >>>> builder inset: 5. >>>> builder extent: 300@400. >>>> builder origin: 10@30. >>>> >>>> "Some node-specific customization" >>>> builder fillNodes: [ :n | (n > 40) ] withColor: (Color white). >>>> builder fillNode: 50 withColor: (Color yellow). >>>> builder fillNode: 43 withColor: (Color green). >>>> >>>> builder strokeNodes: [ :n | (n \ 2) = 1 ] withColor: (Color blue). >>>> builder strokeNode: 13 withColor: (Color black). >>>> >>>> builder strokeNodes: [ :n | (n \ 6) = 0 ] withWidth: 2. >>>> builder strokeNode: 3 withColor: (Color red). >>>> builder strokeNode: 3 withWidth: 3. >>>> >>>> "Using the #drawOn: message for compatibility with ROMondrianViewBuilder" >>>> view := ROView new. >>>> view @ RODraggable. >>>> builder drawOn: view. >>>> view open. >>> >>> And the resulting tree map @ https://dl.dropboxusercontent.com/u/6281855/updated-treemap.png >>> >>> Now I am converting from z-ordering to nesting. Stay tuned ;) >>> >>> Cheers, >>> Roby >>> >>>> On Oct 7, 2013, at 7:33 PM, Alexandre Bergel alexandre.bergel@me.com wrote: >>>> >>>> Looks good to me. >>>> Maybe you could have in addition to >>>> DFTreeMapBuilder>>associations: >>>> something >>>> DFTreeMapBuilder>>parent: aBlockOrASymbol >>>> >>>> Also, something very important that I forgot to mention, we need a method DFTreeMapBuilder>>drawOn: aROView >>>> >>>> Like that, we should be able to have a treemap when using the mondrian builder. Using your example, we should have exactly the same result if we do: >>>> -=-=-=-=-=-=-=-=-=-=-=-= >>>> builder := DFTreeMapBuilder new. >>>> builder ... // your example here >>>> >>>> view := ROView new. >>>> builder drawOn: view. >>>> view open >>>> -=-=-=-=-=-=-=-=-=-=-=-= >>>> >>>> Cheers, >>>> Alexandre >>>> >>>> >>>>> On Oct 7, 2013, at 1:07 PM, "roberto.minelli@usi.ch" roberto.minelli@usi.ch wrote: >>>>> >>>>> Hi, >>>>> >>>>> I finished the first version of the new tree map builder for Roassal. >>>>> >>>>> You can find the source code in my SmalltalkHub package 'DevFlow-View'! >>>>> >>>>> Gofer new >>>>> smalltalkhubUser: 'RobertoMinelli' project: 'DevFlow'; >>>>> package: 'DevFlow-View'; >>>>> load. >>>>> >>>>> Here's an example usage: >>>>> >>>>> builder := DFTreeMapBuilder new. >>>>> builder weightBlock: [ :el | el ]. >>>>> builder nodes: (1 to: 50). >>>>> builder associations: (builder nodes allButFirst collect: [:each | (each // 2) -> each ]). >>>>> >>>>> "Some optional configurations parameters" >>>>> colors := Color white mix: Color blue shades: (builder nodes size). >>>>> builder colorBlock: [ :el | colors at: el ]. >>>>> builder rootColor: ((Color red) alpha: 0.5). >>>>> builder inset: 5. >>>>> builder extent: 500@300. >>>>> builder origin: 10@30. >>>>> >>>>> builder draw. >>>>> >>>>> And the resulting tree map! >>>>> >>>>> [cid:EC2669CC-CA97-4B81-8B1B-B792FBE1C04F@mobile.usilu.net] >>>>> >>>>> Please tell me what do you think! >>>>> >>>>> The next steps are: >>>>> - Add customizable interactions >>>>> - Remove z-ordering and use proper nesting >>>>> - Eventually unroll the recursion in the layout algorithm >>>>> >>>>> Cheers, >>>>> Roberto >>>> >>>> -- >>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>> 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
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"
-- 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
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
Hi,
Great! Alex? :)
About your question: the effect looks as if the rectangle is drawn with multiple lines, and thus when overlapping, the colors are composed.
Cheers, Doru
On Thu, Oct 10, 2013 at 10:49 PM, roberto.minelli@usi.ch < roberto.minelli@usi.ch> wrote:
Hi,
I renamed all the classes which compose the tree map builder to RO* and they are ready for prime time (i.e., integration in Roassal or Moose).
In addition I provided a ROTreeMapBuilderExample with 10-ish examples on how to use the builder. I should comment the code, but I will do that tomorrow ;) I also committed a specialization of the ROBorder, a ROInnerBorder. As the class name says, it creates the border within the element's shape (i.e., better when lay outing). It's not fully functional, but I already tried out on my tree map and most of the times is ok ;)
Waiting for your feedback and comments.
P.s.: Why if a ROLine is filled with a translucent color its begin and end points are shaded-ish? Here's a screenshot @ https://dl.dropboxusercontent.com/u/6281855/gradient-begin-end.png
Cheers, Roby
On Oct 10, 2013, at 8:26 AM, roberto.minelli@usi.ch wrote:
On Oct 9, 2013, at 9:31 PM, Tudor Girba tudor@tudorgirba.com wrote:
Nice! I want this integrated in Roassal, or at least in Moose. Alex?
Would be cool!
About LinearColorNormalizer vs. mix:shades:.
LinearColorNormalizer is better in that it does not create the actual
colors. Imagine that you have 2 nodes: one with weight 1 and one with weight 10000. Using mix:shades: you will generate 10000 shades. With LinearColorNormalizer you will generate exactly 2.
Oh, I see. I will probably switch to the color normalizer then!
Doru
On Wed, Oct 9, 2013 at 11:43 AM, roberto.minelli@usi.ch <
roberto.minelli@usi.ch> wrote:
Now you can shade strokes with the message
#withShadedFramesFromColor:toColor:.
HoweverI kept the default shading with the message #withShadedFrames
with hardcoded strategy & color.
Cheers, Roby
On Oct 9, 2013, at 11:28 AM, "roberto.minelli@usi.ch" <
roberto.minelli@usi.ch>
wrote:
Hi Doru,
I just added options for shading (on nodes this time) so that you do
not have to care about the colors explicitly.
Now we have the messages for:
- #withShadesOnWeightFromColor:toColor: --> Applies the shading on the
weight of the node
- #withShadesOnNestingFromColor:toColor: --> Applies the shading on
the nesting level of the node
What's the real difference between a LinearColorNormalizer and
#mix:shades: I really like #mix:shades: :D
In a minute I will also provide what you said for the shaded frames:
#withShadedFrames was an example on how to produce framed tree maps with a single message ;)
Cheers, Roby
On Oct 9, 2013, at 10:47 AM, Tudor Girba tudor@tudorgirba.com wrote:
Ok, I took a closer look and you already implemented almost what I
said :).
So, let's take a look: withShadedFrames self inset: 1. self strokeAllNodesWithColorBlock: [ :el | Color darkGray darker adjustSaturation: (-0.03 * el
depth) brightness: (el depth * 0.08).
].This is a good start, but:
- Color darkGray should not be hardcoded
- The actual darkening strategy should not be hardcoded either
I would suggest to use a LinearColorNormalizer instead. This allows
you to specify both the min and max color. What do you say?
Cheers, Doru
On Wed, Oct 9, 2013 at 10:11 AM, Tudor Girba tudor@tudorgirba.com
wrote:
Nice!
I just do not understand why colors has the same size as the nodes
collection. It should have the same size as the max nesting level. What do I get wrong?
In any case, I think for shading we need also strategy that hides the
implementation details (so, no explicit color creation). I think that we can just give a min and a max and then simply use a linear color normalizer internally. Of course, we also need a way to marry such an implicit strategy with the possibility of custom colors :). Proposals?
Doru
On Wed, Oct 9, 2013 at 10:02 AM, roberto.minelli@usi.ch <
roberto.minelli@usi.ch> wrote:
Sorry, DropBox messed up the image name. I updated the file ;)
On Oct 9, 2013, at 9:57 AM, Yuriy Tymchuk yuriy.tymchuk@me.com
wrote:
404 on dropbox
On Oct 9, 2013, at 9:30 AM, roberto.minelli@usi.ch wrote:
> Here is another way to visualize the nesting, with frames. It's
enough to call #withShadedFrames. How cool is that?
> > Here's a sample visualization @
https://dl.dropboxusercontent.com/u/6281855/treemap-frames.png
> > And here's the script: >
=-=-=--=-=-=-=-=-=--=-=-=-=-=-=--=-=-=-=-=-=--=-=-=-=-=-=--=-=-=-=-=-=--=-=-=-=-=-=--=-=-=-=-=-=--=-=-=-
> > builder := DFTreeMapBuilder new. > builder weightBlock: [ :el | el ]. > builder nodes: (1 to: 100). > builder nestingFromAssociations: (builder nodes allButFirst
collect: [:each | (each // 2) -> each ]).
> > "Some optional configurations parameters" > colors := (Color lightBlue) mix: Color blue shades: (builder nodes
size).
> builder colorBlock: [ :el | colors at: el ]. > builder rootColor: (Color red). > builder extent: 521@312. > builder origin: 20@20. > > builder withShadedFrames. > > builder draw. >
=-=-=--=-=-=-=-=-=--=-=-=-=-=-=--=-=-=-=-=-=--=-=-=-=-=-=--=-=-=-=-=-=--=-=-=-=-=-=--=-=-=-=-=-=--=-=-=-
> > Roby > > On Oct 9, 2013, at 8:12 AM, "roberto.minelli@usi.ch" <
roberto.minelli@usi.ch>
> wrote: > >> And yes, now the tree map builder does no longer use z-ordering to
lay out the elements ;)
>> >> On Oct 8, 2013, at 12:51 PM, Alexandre Bergel <
alexandre.bergel@me.com> wrote:
>> >>> Ok, excellent!!! >>> >>> Alexandre >>> >>>> Le 08-10-2013 à 6:44, "roberto.minelli@usi.ch" <
roberto.minelli@usi.ch> a écrit :
>>>> >>>> Hi, >>>> >>>> I made a couple of changes of the builder as per your
suggestions. An updated usage script would be:
>>>> >>>>> builder := DFTreeMapBuilder new. >>>>> builder weightBlock: [ :el | el ]. >>>>> builder nodes: (1 to: 50). >>>>> builder nestingFromAssociations: (builder nodes allButFirst
collect: [:each | (each // 2) -> each ]).
>>>>> >>>>> "Some optional configurations parameters" >>>>> colors := Color green mix: Color blue shades: (builder nodes
size).
>>>>> builder colorBlock: [ :el | colors at: el ]. >>>>> builder rootColor: ((Color red) alpha: 0.5). >>>>> builder inset: 5. >>>>> builder extent: 300@400. >>>>> builder origin: 10@30. >>>>> >>>>> "Some node-specific customization" >>>>> builder fillNodes: [ :n | (n > 40) ] withColor: (Color white). >>>>> builder fillNode: 50 withColor: (Color yellow). >>>>> builder fillNode: 43 withColor: (Color green). >>>>> >>>>> builder strokeNodes: [ :n | (n \ 2) = 1 ] withColor: (Color
blue).
>>>>> builder strokeNode: 13 withColor: (Color black). >>>>> >>>>> builder strokeNodes: [ :n | (n \ 6) = 0 ] withWidth: 2. >>>>> builder strokeNode: 3 withColor: (Color red). >>>>> builder strokeNode: 3 withWidth: 3. >>>>> >>>>> "Using the #drawOn: message for compatibility with
ROMondrianViewBuilder"
>>>>> view := ROView new. >>>>> view @ RODraggable. >>>>> builder drawOn: view. >>>>> view open. >>>> >>>> And the resulting tree map @
https://dl.dropboxusercontent.com/u/6281855/updated-treemap.png
>>>> >>>> Now I am converting from z-ordering to nesting. Stay tuned ;) >>>> >>>> Cheers, >>>> Roby >>>> >>>>> On Oct 7, 2013, at 7:33 PM, Alexandre Bergel <
alexandre.bergel@me.com> wrote:
>>>>> >>>>> Looks good to me. >>>>> Maybe you could have in addition to >>>>> DFTreeMapBuilder>>associations: >>>>> something >>>>> DFTreeMapBuilder>>parent: aBlockOrASymbol >>>>> >>>>> Also, something very important that I forgot to mention, we
need a method DFTreeMapBuilder>>drawOn: aROView
>>>>> >>>>> Like that, we should be able to have a treemap when using the
mondrian builder. Using your example, we should have exactly the same result if we do:
>>>>> -=-=-=-=-=-=-=-=-=-=-=-= >>>>> builder := DFTreeMapBuilder new. >>>>> builder ... // your example here >>>>> >>>>> view := ROView new. >>>>> builder drawOn: view. >>>>> view open >>>>> -=-=-=-=-=-=-=-=-=-=-=-= >>>>> >>>>> Cheers, >>>>> Alexandre >>>>> >>>>> >>>>>> On Oct 7, 2013, at 1:07 PM, "roberto.minelli@usi.ch" <
roberto.minelli@usi.ch> wrote:
>>>>>> >>>>>> Hi, >>>>>> >>>>>> I finished the first version of the new tree map builder for
Roassal.
>>>>>> >>>>>> You can find the source code in my SmalltalkHub package
'DevFlow-View'!
>>>>>> >>>>>> Gofer new >>>>>> smalltalkhubUser: 'RobertoMinelli' project: 'DevFlow'; >>>>>> package: 'DevFlow-View'; >>>>>> load. >>>>>> >>>>>> Here's an example usage: >>>>>> >>>>>> builder := DFTreeMapBuilder new. >>>>>> builder weightBlock: [ :el | el ]. >>>>>> builder nodes: (1 to: 50). >>>>>> builder associations: (builder nodes allButFirst collect:
[:each | (each // 2) -> each ]).
>>>>>> >>>>>> "Some optional configurations parameters" >>>>>> colors := Color white mix: Color blue shades: (builder nodes
size).
>>>>>> builder colorBlock: [ :el | colors at: el ]. >>>>>> builder rootColor: ((Color red) alpha: 0.5). >>>>>> builder inset: 5. >>>>>> builder extent: 500@300. >>>>>> builder origin: 10@30. >>>>>> >>>>>> builder draw. >>>>>> >>>>>> And the resulting tree map! >>>>>> >>>>>> [cid:EC2669CC-CA97-4B81-8B1B-B792FBE1C04F@mobile.usilu.net] >>>>>> >>>>>> Please tell me what do you think! >>>>>> >>>>>> The next steps are: >>>>>> - Add customizable interactions >>>>>> - Remove z-ordering and use proper nesting >>>>>> - Eventually unroll the recursion in the layout algorithm >>>>>> >>>>>> Cheers, >>>>>> Roberto >>>>> >>>>> -- >>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>>> 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
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"
-- 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
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
Great! Alex? :)
Today I will integrate Roberto's work.
About your question: the effect looks as if the rectangle is drawn with multiple lines, and thus when overlapping, the colors are composed.
Exactly. I know how to fix this. Today I will work on this.
Cheers, Alexandre
On Thu, Oct 10, 2013 at 10:49 PM, roberto.minelli@usi.ch roberto.minelli@usi.ch wrote: Hi,
I renamed all the classes which compose the tree map builder to RO* and they are ready for prime time (i.e., integration in Roassal or Moose).
In addition I provided a ROTreeMapBuilderExample with 10-ish examples on how to use the builder. I should comment the code, but I will do that tomorrow ;) I also committed a specialization of the ROBorder, a ROInnerBorder. As the class name says, it creates the border within the element's shape (i.e., better when lay outing). It's not fully functional, but I already tried out on my tree map and most of the times is ok ;)
Waiting for your feedback and comments.
P.s.: Why if a ROLine is filled with a translucent color its begin and end points are shaded-ish? Here's a screenshot @ https://dl.dropboxusercontent.com/u/6281855/gradient-begin-end.png
Cheers, Roby
On Oct 10, 2013, at 8:26 AM, roberto.minelli@usi.ch wrote:
On Oct 9, 2013, at 9:31 PM, Tudor Girba tudor@tudorgirba.com wrote:
Nice! I want this integrated in Roassal, or at least in Moose. Alex?
Would be cool!
About LinearColorNormalizer vs. mix:shades:.
LinearColorNormalizer is better in that it does not create the actual colors. Imagine that you have 2 nodes: one with weight 1 and one with weight 10000. Using mix:shades: you will generate 10000 shades. With LinearColorNormalizer you will generate exactly 2.
Oh, I see. I will probably switch to the color normalizer then!
Doru
On Wed, Oct 9, 2013 at 11:43 AM, roberto.minelli@usi.ch roberto.minelli@usi.ch wrote: Now you can shade strokes with the message #withShadedFramesFromColor:toColor:. HoweverI kept the default shading with the message #withShadedFrames with hardcoded strategy & color.
Cheers, Roby
On Oct 9, 2013, at 11:28 AM, "roberto.minelli@usi.ch" roberto.minelli@usi.ch wrote:
Hi Doru,
I just added options for shading (on nodes this time) so that you do not have to care about the colors explicitly.
Now we have the messages for:
- #withShadesOnWeightFromColor:toColor: --> Applies the shading on the weight of the node
- #withShadesOnNestingFromColor:toColor: --> Applies the shading on the nesting level of the node
What's the real difference between a LinearColorNormalizer and #mix:shades: I really like #mix:shades: :D
In a minute I will also provide what you said for the shaded frames: #withShadedFrames was an example on how to produce framed tree maps with a single message ;)
Cheers, Roby
On Oct 9, 2013, at 10:47 AM, Tudor Girba tudor@tudorgirba.com wrote:
Ok, I took a closer look and you already implemented almost what I said :).
So, let's take a look: withShadedFrames self inset: 1. self strokeAllNodesWithColorBlock: [ :el | Color darkGray darker adjustSaturation: (-0.03 * el depth) brightness: (el depth * 0.08). ].
This is a good start, but:
- Color darkGray should not be hardcoded
- The actual darkening strategy should not be hardcoded either
I would suggest to use a LinearColorNormalizer instead. This allows you to specify both the min and max color. What do you say?
Cheers, Doru
On Wed, Oct 9, 2013 at 10:11 AM, Tudor Girba tudor@tudorgirba.com wrote: Nice!
I just do not understand why colors has the same size as the nodes collection. It should have the same size as the max nesting level. What do I get wrong?
In any case, I think for shading we need also strategy that hides the implementation details (so, no explicit color creation). I think that we can just give a min and a max and then simply use a linear color normalizer internally. Of course, we also need a way to marry such an implicit strategy with the possibility of custom colors :). Proposals?
Doru
On Wed, Oct 9, 2013 at 10:02 AM, roberto.minelli@usi.ch roberto.minelli@usi.ch wrote: Sorry, DropBox messed up the image name. I updated the file ;)
On Oct 9, 2013, at 9:57 AM, Yuriy Tymchuk yuriy.tymchuk@me.com wrote:
404 on dropbox
On Oct 9, 2013, at 9:30 AM, roberto.minelli@usi.ch wrote:
> Here is another way to visualize the nesting, with frames. It's enough to call #withShadedFrames. How cool is that? > > Here's a sample visualization @ https://dl.dropboxusercontent.com/u/6281855/treemap-frames.png > > And here's the script: > =-=-=--=-=-=-=-=-=--=-=-=-=-=-=--=-=-=-=-=-=--=-=-=-=-=-=--=-=-=-=-=-=--=-=-=-=-=-=--=-=-=-=-=-=--=-=-=- > > builder := DFTreeMapBuilder new. > builder weightBlock: [ :el | el ]. > builder nodes: (1 to: 100). > builder nestingFromAssociations: (builder nodes allButFirst collect: [:each | (each // 2) -> each ]). > > "Some optional configurations parameters" > colors := (Color lightBlue) mix: Color blue shades: (builder nodes size). > builder colorBlock: [ :el | colors at: el ]. > builder rootColor: (Color red). > builder extent: 521@312. > builder origin: 20@20. > > builder withShadedFrames. > > builder draw. > =-=-=--=-=-=-=-=-=--=-=-=-=-=-=--=-=-=-=-=-=--=-=-=-=-=-=--=-=-=-=-=-=--=-=-=-=-=-=--=-=-=-=-=-=--=-=-=- > > Roby > > On Oct 9, 2013, at 8:12 AM, "roberto.minelli@usi.ch" roberto.minelli@usi.ch > wrote: > >> And yes, now the tree map builder does no longer use z-ordering to lay out the elements ;) >> >> On Oct 8, 2013, at 12:51 PM, Alexandre Bergel alexandre.bergel@me.com wrote: >> >>> Ok, excellent!!! >>> >>> Alexandre >>> >>>> Le 08-10-2013 à 6:44, "roberto.minelli@usi.ch" roberto.minelli@usi.ch a écrit : >>>> >>>> Hi, >>>> >>>> I made a couple of changes of the builder as per your suggestions. An updated usage script would be: >>>> >>>>> builder := DFTreeMapBuilder new. >>>>> builder weightBlock: [ :el | el ]. >>>>> builder nodes: (1 to: 50). >>>>> builder nestingFromAssociations: (builder nodes allButFirst collect: [:each | (each // 2) -> each ]). >>>>> >>>>> "Some optional configurations parameters" >>>>> colors := Color green mix: Color blue shades: (builder nodes size). >>>>> builder colorBlock: [ :el | colors at: el ]. >>>>> builder rootColor: ((Color red) alpha: 0.5). >>>>> builder inset: 5. >>>>> builder extent: 300@400. >>>>> builder origin: 10@30. >>>>> >>>>> "Some node-specific customization" >>>>> builder fillNodes: [ :n | (n > 40) ] withColor: (Color white). >>>>> builder fillNode: 50 withColor: (Color yellow). >>>>> builder fillNode: 43 withColor: (Color green). >>>>> >>>>> builder strokeNodes: [ :n | (n \ 2) = 1 ] withColor: (Color blue). >>>>> builder strokeNode: 13 withColor: (Color black). >>>>> >>>>> builder strokeNodes: [ :n | (n \ 6) = 0 ] withWidth: 2. >>>>> builder strokeNode: 3 withColor: (Color red). >>>>> builder strokeNode: 3 withWidth: 3. >>>>> >>>>> "Using the #drawOn: message for compatibility with ROMondrianViewBuilder" >>>>> view := ROView new. >>>>> view @ RODraggable. >>>>> builder drawOn: view. >>>>> view open. >>>> >>>> And the resulting tree map @ https://dl.dropboxusercontent.com/u/6281855/updated-treemap.png >>>> >>>> Now I am converting from z-ordering to nesting. Stay tuned ;) >>>> >>>> Cheers, >>>> Roby >>>> >>>>> On Oct 7, 2013, at 7:33 PM, Alexandre Bergel alexandre.bergel@me.com wrote: >>>>> >>>>> Looks good to me. >>>>> Maybe you could have in addition to >>>>> DFTreeMapBuilder>>associations: >>>>> something >>>>> DFTreeMapBuilder>>parent: aBlockOrASymbol >>>>> >>>>> Also, something very important that I forgot to mention, we need a method DFTreeMapBuilder>>drawOn: aROView >>>>> >>>>> Like that, we should be able to have a treemap when using the mondrian builder. Using your example, we should have exactly the same result if we do: >>>>> -=-=-=-=-=-=-=-=-=-=-=-= >>>>> builder := DFTreeMapBuilder new. >>>>> builder ... // your example here >>>>> >>>>> view := ROView new. >>>>> builder drawOn: view. >>>>> view open >>>>> -=-=-=-=-=-=-=-=-=-=-=-= >>>>> >>>>> Cheers, >>>>> Alexandre >>>>> >>>>> >>>>>> On Oct 7, 2013, at 1:07 PM, "roberto.minelli@usi.ch" roberto.minelli@usi.ch wrote: >>>>>> >>>>>> Hi, >>>>>> >>>>>> I finished the first version of the new tree map builder for Roassal. >>>>>> >>>>>> You can find the source code in my SmalltalkHub package 'DevFlow-View'! >>>>>> >>>>>> Gofer new >>>>>> smalltalkhubUser: 'RobertoMinelli' project: 'DevFlow'; >>>>>> package: 'DevFlow-View'; >>>>>> load. >>>>>> >>>>>> Here's an example usage: >>>>>> >>>>>> builder := DFTreeMapBuilder new. >>>>>> builder weightBlock: [ :el | el ]. >>>>>> builder nodes: (1 to: 50). >>>>>> builder associations: (builder nodes allButFirst collect: [:each | (each // 2) -> each ]). >>>>>> >>>>>> "Some optional configurations parameters" >>>>>> colors := Color white mix: Color blue shades: (builder nodes size). >>>>>> builder colorBlock: [ :el | colors at: el ]. >>>>>> builder rootColor: ((Color red) alpha: 0.5). >>>>>> builder inset: 5. >>>>>> builder extent: 500@300. >>>>>> builder origin: 10@30. >>>>>> >>>>>> builder draw. >>>>>> >>>>>> And the resulting tree map! >>>>>> >>>>>> [cid:EC2669CC-CA97-4B81-8B1B-B792FBE1C04F@mobile.usilu.net] >>>>>> >>>>>> Please tell me what do you think! >>>>>> >>>>>> The next steps are: >>>>>> - Add customizable interactions >>>>>> - Remove z-ordering and use proper nesting >>>>>> - Eventually unroll the recursion in the layout algorithm >>>>>> >>>>>> Cheers, >>>>>> Roberto >>>>> >>>>> -- >>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>>> 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
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"
-- 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
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
-- www.tudorgirba.com
"Every thing has its own flow"
On Oct 11, 2013, at 1:44 PM, Alexandre Bergel alexandre.bergel@me.com wrote:
Great! Alex? :)
Today I will integrate Roberto's work.
Cool, let me know if I can be of any help. Have you seen the examples? The class ROTreeMapBuilderExample is compliant with ROExample, so if you add ROTreeMapBuilderExample to the classes array in the ROEaselMorphic>>#showExamplesOnView: it works. Then you probably want to copy ROTreeMapBuilderExample 's methods to ROExample ;)
About your question: the effect looks as if the rectangle is drawn with multiple lines, and thus when overlapping, the colors are composed.
Exactly. I know how to fix this. Today I will work on this.
Great!
Cheers, Alexandre
Cheers, Roby
On Thu, Oct 10, 2013 at 10:49 PM, roberto.minelli@usi.ch roberto.minelli@usi.ch wrote: Hi,
I renamed all the classes which compose the tree map builder to RO* and they are ready for prime time (i.e., integration in Roassal or Moose).
In addition I provided a ROTreeMapBuilderExample with 10-ish examples on how to use the builder. I should comment the code, but I will do that tomorrow ;) I also committed a specialization of the ROBorder, a ROInnerBorder. As the class name says, it creates the border within the element's shape (i.e., better when lay outing). It's not fully functional, but I already tried out on my tree map and most of the times is ok ;)
Waiting for your feedback and comments.
P.s.: Why if a ROLine is filled with a translucent color its begin and end points are shaded-ish? Here's a screenshot @ https://dl.dropboxusercontent.com/u/6281855/gradient-begin-end.png
Cheers, Roby
On Oct 10, 2013, at 8:26 AM, roberto.minelli@usi.ch wrote:
On Oct 9, 2013, at 9:31 PM, Tudor Girba tudor@tudorgirba.com wrote:
Nice! I want this integrated in Roassal, or at least in Moose. Alex?
Would be cool!
About LinearColorNormalizer vs. mix:shades:.
LinearColorNormalizer is better in that it does not create the actual colors. Imagine that you have 2 nodes: one with weight 1 and one with weight 10000. Using mix:shades: you will generate 10000 shades. With LinearColorNormalizer you will generate exactly 2.
Oh, I see. I will probably switch to the color normalizer then!
Doru
On Wed, Oct 9, 2013 at 11:43 AM, roberto.minelli@usi.ch roberto.minelli@usi.ch wrote: Now you can shade strokes with the message #withShadedFramesFromColor:toColor:. HoweverI kept the default shading with the message #withShadedFrames with hardcoded strategy & color.
Cheers, Roby
On Oct 9, 2013, at 11:28 AM, "roberto.minelli@usi.ch" roberto.minelli@usi.ch wrote:
Hi Doru,
I just added options for shading (on nodes this time) so that you do not have to care about the colors explicitly.
Now we have the messages for:
- #withShadesOnWeightFromColor:toColor: --> Applies the shading on the weight of the node
- #withShadesOnNestingFromColor:toColor: --> Applies the shading on the nesting level of the node
What's the real difference between a LinearColorNormalizer and #mix:shades: I really like #mix:shades: :D
In a minute I will also provide what you said for the shaded frames: #withShadedFrames was an example on how to produce framed tree maps with a single message ;)
Cheers, Roby
On Oct 9, 2013, at 10:47 AM, Tudor Girba tudor@tudorgirba.com wrote:
Ok, I took a closer look and you already implemented almost what I said :).
So, let's take a look: withShadedFrames self inset: 1. self strokeAllNodesWithColorBlock: [ :el | Color darkGray darker adjustSaturation: (-0.03 * el depth) brightness: (el depth * 0.08). ].
This is a good start, but:
- Color darkGray should not be hardcoded
- The actual darkening strategy should not be hardcoded either
I would suggest to use a LinearColorNormalizer instead. This allows you to specify both the min and max color. What do you say?
Cheers, Doru
On Wed, Oct 9, 2013 at 10:11 AM, Tudor Girba tudor@tudorgirba.com wrote: Nice!
I just do not understand why colors has the same size as the nodes collection. It should have the same size as the max nesting level. What do I get wrong?
In any case, I think for shading we need also strategy that hides the implementation details (so, no explicit color creation). I think that we can just give a min and a max and then simply use a linear color normalizer internally. Of course, we also need a way to marry such an implicit strategy with the possibility of custom colors :). Proposals?
Doru
On Wed, Oct 9, 2013 at 10:02 AM, roberto.minelli@usi.ch roberto.minelli@usi.ch wrote: Sorry, DropBox messed up the image name. I updated the file ;)
On Oct 9, 2013, at 9:57 AM, Yuriy Tymchuk yuriy.tymchuk@me.com wrote:
> 404 on dropbox > > On Oct 9, 2013, at 9:30 AM, roberto.minelli@usi.ch wrote: > >> Here is another way to visualize the nesting, with frames. It's enough to call #withShadedFrames. How cool is that? >> >> Here's a sample visualization @ https://dl.dropboxusercontent.com/u/6281855/treemap-frames.png >> >> And here's the script: >> =-=-=--=-=-=-=-=-=--=-=-=-=-=-=--=-=-=-=-=-=--=-=-=-=-=-=--=-=-=-=-=-=--=-=-=-=-=-=--=-=-=-=-=-=--=-=-=- >> >> builder := DFTreeMapBuilder new. >> builder weightBlock: [ :el | el ]. >> builder nodes: (1 to: 100). >> builder nestingFromAssociations: (builder nodes allButFirst collect: [:each | (each // 2) -> each ]). >> >> "Some optional configurations parameters" >> colors := (Color lightBlue) mix: Color blue shades: (builder nodes size). >> builder colorBlock: [ :el | colors at: el ]. >> builder rootColor: (Color red). >> builder extent: 521@312. >> builder origin: 20@20. >> >> builder withShadedFrames. >> >> builder draw. >> =-=-=--=-=-=-=-=-=--=-=-=-=-=-=--=-=-=-=-=-=--=-=-=-=-=-=--=-=-=-=-=-=--=-=-=-=-=-=--=-=-=-=-=-=--=-=-=- >> >> Roby >> >> On Oct 9, 2013, at 8:12 AM, "roberto.minelli@usi.ch" roberto.minelli@usi.ch >> wrote: >> >>> And yes, now the tree map builder does no longer use z-ordering to lay out the elements ;) >>> >>> On Oct 8, 2013, at 12:51 PM, Alexandre Bergel alexandre.bergel@me.com wrote: >>> >>>> Ok, excellent!!! >>>> >>>> Alexandre >>>> >>>>> Le 08-10-2013 à 6:44, "roberto.minelli@usi.ch" roberto.minelli@usi.ch a écrit : >>>>> >>>>> Hi, >>>>> >>>>> I made a couple of changes of the builder as per your suggestions. An updated usage script would be: >>>>> >>>>>> builder := DFTreeMapBuilder new. >>>>>> builder weightBlock: [ :el | el ]. >>>>>> builder nodes: (1 to: 50). >>>>>> builder nestingFromAssociations: (builder nodes allButFirst collect: [:each | (each // 2) -> each ]). >>>>>> >>>>>> "Some optional configurations parameters" >>>>>> colors := Color green mix: Color blue shades: (builder nodes size). >>>>>> builder colorBlock: [ :el | colors at: el ]. >>>>>> builder rootColor: ((Color red) alpha: 0.5). >>>>>> builder inset: 5. >>>>>> builder extent: 300@400. >>>>>> builder origin: 10@30. >>>>>> >>>>>> "Some node-specific customization" >>>>>> builder fillNodes: [ :n | (n > 40) ] withColor: (Color white). >>>>>> builder fillNode: 50 withColor: (Color yellow). >>>>>> builder fillNode: 43 withColor: (Color green). >>>>>> >>>>>> builder strokeNodes: [ :n | (n \ 2) = 1 ] withColor: (Color blue). >>>>>> builder strokeNode: 13 withColor: (Color black). >>>>>> >>>>>> builder strokeNodes: [ :n | (n \ 6) = 0 ] withWidth: 2. >>>>>> builder strokeNode: 3 withColor: (Color red). >>>>>> builder strokeNode: 3 withWidth: 3. >>>>>> >>>>>> "Using the #drawOn: message for compatibility with ROMondrianViewBuilder" >>>>>> view := ROView new. >>>>>> view @ RODraggable. >>>>>> builder drawOn: view. >>>>>> view open. >>>>> >>>>> And the resulting tree map @ https://dl.dropboxusercontent.com/u/6281855/updated-treemap.png >>>>> >>>>> Now I am converting from z-ordering to nesting. Stay tuned ;) >>>>> >>>>> Cheers, >>>>> Roby >>>>> >>>>>> On Oct 7, 2013, at 7:33 PM, Alexandre Bergel alexandre.bergel@me.com wrote: >>>>>> >>>>>> Looks good to me. >>>>>> Maybe you could have in addition to >>>>>> DFTreeMapBuilder>>associations: >>>>>> something >>>>>> DFTreeMapBuilder>>parent: aBlockOrASymbol >>>>>> >>>>>> Also, something very important that I forgot to mention, we need a method DFTreeMapBuilder>>drawOn: aROView >>>>>> >>>>>> Like that, we should be able to have a treemap when using the mondrian builder. Using your example, we should have exactly the same result if we do: >>>>>> -=-=-=-=-=-=-=-=-=-=-=-= >>>>>> builder := DFTreeMapBuilder new. >>>>>> builder ... // your example here >>>>>> >>>>>> view := ROView new. >>>>>> builder drawOn: view. >>>>>> view open >>>>>> -=-=-=-=-=-=-=-=-=-=-=-= >>>>>> >>>>>> Cheers, >>>>>> Alexandre >>>>>> >>>>>> >>>>>>> On Oct 7, 2013, at 1:07 PM, "roberto.minelli@usi.ch" roberto.minelli@usi.ch wrote: >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> I finished the first version of the new tree map builder for Roassal. >>>>>>> >>>>>>> You can find the source code in my SmalltalkHub package 'DevFlow-View'! >>>>>>> >>>>>>> Gofer new >>>>>>> smalltalkhubUser: 'RobertoMinelli' project: 'DevFlow'; >>>>>>> package: 'DevFlow-View'; >>>>>>> load. >>>>>>> >>>>>>> Here's an example usage: >>>>>>> >>>>>>> builder := DFTreeMapBuilder new. >>>>>>> builder weightBlock: [ :el | el ]. >>>>>>> builder nodes: (1 to: 50). >>>>>>> builder associations: (builder nodes allButFirst collect: [:each | (each // 2) -> each ]). >>>>>>> >>>>>>> "Some optional configurations parameters" >>>>>>> colors := Color white mix: Color blue shades: (builder nodes size). >>>>>>> builder colorBlock: [ :el | colors at: el ]. >>>>>>> builder rootColor: ((Color red) alpha: 0.5). >>>>>>> builder inset: 5. >>>>>>> builder extent: 500@300. >>>>>>> builder origin: 10@30. >>>>>>> >>>>>>> builder draw. >>>>>>> >>>>>>> And the resulting tree map! >>>>>>> >>>>>>> [cid:EC2669CC-CA97-4B81-8B1B-B792FBE1C04F@mobile.usilu.net] >>>>>>> >>>>>>> Please tell me what do you think! >>>>>>> >>>>>>> The next steps are: >>>>>>> - Add customizable interactions >>>>>>> - Remove z-ordering and use proper nesting >>>>>>> - Eventually unroll the recursion in the layout algorithm >>>>>>> >>>>>>> Cheers, >>>>>>> Roberto >>>>>> >>>>>> -- >>>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>>>> 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 > > > _______________________________________________ > 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"
-- 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
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
-- www.tudorgirba.com
"Every thing has its own flow"
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Roberto, you have done an amazing job. Great great great!
Your tree map is now in! The Roassal easel recognizes it.
Cheers, Alexandre
On Oct 11, 2013, at 8:52 AM, roberto.minelli@usi.ch wrote:
On Oct 11, 2013, at 1:44 PM, Alexandre Bergel alexandre.bergel@me.com wrote:
Great! Alex? :)
Today I will integrate Roberto's work.
Cool, let me know if I can be of any help. Have you seen the examples? The class ROTreeMapBuilderExample is compliant with ROExample, so if you add ROTreeMapBuilderExample to the classes array in the ROEaselMorphic>>#showExamplesOnView: it works. Then you probably want to copy ROTreeMapBuilderExample 's methods to ROExample ;)
About your question: the effect looks as if the rectangle is drawn with multiple lines, and thus when overlapping, the colors are composed.
Exactly. I know how to fix this. Today I will work on this.
Great!
Cheers, Alexandre
Cheers, Roby
On Thu, Oct 10, 2013 at 10:49 PM, roberto.minelli@usi.ch roberto.minelli@usi.ch wrote: Hi,
I renamed all the classes which compose the tree map builder to RO* and they are ready for prime time (i.e., integration in Roassal or Moose).
In addition I provided a ROTreeMapBuilderExample with 10-ish examples on how to use the builder. I should comment the code, but I will do that tomorrow ;) I also committed a specialization of the ROBorder, a ROInnerBorder. As the class name says, it creates the border within the element's shape (i.e., better when lay outing). It's not fully functional, but I already tried out on my tree map and most of the times is ok ;)
Waiting for your feedback and comments.
P.s.: Why if a ROLine is filled with a translucent color its begin and end points are shaded-ish? Here's a screenshot @ https://dl.dropboxusercontent.com/u/6281855/gradient-begin-end.png
Cheers, Roby
On Oct 10, 2013, at 8:26 AM, roberto.minelli@usi.ch wrote:
On Oct 9, 2013, at 9:31 PM, Tudor Girba tudor@tudorgirba.com wrote:
Nice! I want this integrated in Roassal, or at least in Moose. Alex?
Would be cool!
About LinearColorNormalizer vs. mix:shades:.
LinearColorNormalizer is better in that it does not create the actual colors. Imagine that you have 2 nodes: one with weight 1 and one with weight 10000. Using mix:shades: you will generate 10000 shades. With LinearColorNormalizer you will generate exactly 2.
Oh, I see. I will probably switch to the color normalizer then!
Doru
On Wed, Oct 9, 2013 at 11:43 AM, roberto.minelli@usi.ch roberto.minelli@usi.ch wrote: Now you can shade strokes with the message #withShadedFramesFromColor:toColor:. HoweverI kept the default shading with the message #withShadedFrames with hardcoded strategy & color.
Cheers, Roby
On Oct 9, 2013, at 11:28 AM, "roberto.minelli@usi.ch" roberto.minelli@usi.ch wrote:
Hi Doru,
I just added options for shading (on nodes this time) so that you do not have to care about the colors explicitly.
Now we have the messages for:
- #withShadesOnWeightFromColor:toColor: --> Applies the shading on the weight of the node
- #withShadesOnNestingFromColor:toColor: --> Applies the shading on the nesting level of the node
What's the real difference between a LinearColorNormalizer and #mix:shades: I really like #mix:shades: :D
In a minute I will also provide what you said for the shaded frames: #withShadedFrames was an example on how to produce framed tree maps with a single message ;)
Cheers, Roby
On Oct 9, 2013, at 10:47 AM, Tudor Girba tudor@tudorgirba.com wrote:
> Ok, I took a closer look and you already implemented almost what I said :). > > So, let's take a look: > withShadedFrames > self inset: 1. > self strokeAllNodesWithColorBlock: [ :el | > Color darkGray darker adjustSaturation: (-0.03 * el depth) brightness: (el depth * 0.08). > ]. > > This is a good start, but: > - Color darkGray should not be hardcoded > - The actual darkening strategy should not be hardcoded either > > I would suggest to use a LinearColorNormalizer instead. This allows you to specify both the min and max color. What do you say? > > Cheers, > Doru > > > > On Wed, Oct 9, 2013 at 10:11 AM, Tudor Girba tudor@tudorgirba.com wrote: > Nice! > > I just do not understand why colors has the same size as the nodes collection. It should have the same size as the max nesting level. What do I get wrong? > > In any case, I think for shading we need also strategy that hides the implementation details (so, no explicit color creation). I think that we can just give a min and a max and then simply use a linear color normalizer internally. Of course, we also need a way to marry such an implicit strategy with the possibility of custom colors :). Proposals? > > Doru > > > On Wed, Oct 9, 2013 at 10:02 AM, roberto.minelli@usi.ch roberto.minelli@usi.ch wrote: > Sorry, DropBox messed up the image name. I updated the file ;) > > On Oct 9, 2013, at 9:57 AM, Yuriy Tymchuk yuriy.tymchuk@me.com wrote: > >> 404 on dropbox >> >> On Oct 9, 2013, at 9:30 AM, roberto.minelli@usi.ch wrote: >> >>> Here is another way to visualize the nesting, with frames. It's enough to call #withShadedFrames. How cool is that? >>> >>> Here's a sample visualization @ https://dl.dropboxusercontent.com/u/6281855/treemap-frames.png >>> >>> And here's the script: >>> =-=-=--=-=-=-=-=-=--=-=-=-=-=-=--=-=-=-=-=-=--=-=-=-=-=-=--=-=-=-=-=-=--=-=-=-=-=-=--=-=-=-=-=-=--=-=-=- >>> >>> builder := DFTreeMapBuilder new. >>> builder weightBlock: [ :el | el ]. >>> builder nodes: (1 to: 100). >>> builder nestingFromAssociations: (builder nodes allButFirst collect: [:each | (each // 2) -> each ]). >>> >>> "Some optional configurations parameters" >>> colors := (Color lightBlue) mix: Color blue shades: (builder nodes size). >>> builder colorBlock: [ :el | colors at: el ]. >>> builder rootColor: (Color red). >>> builder extent: 521@312. >>> builder origin: 20@20. >>> >>> builder withShadedFrames. >>> >>> builder draw. >>> =-=-=--=-=-=-=-=-=--=-=-=-=-=-=--=-=-=-=-=-=--=-=-=-=-=-=--=-=-=-=-=-=--=-=-=-=-=-=--=-=-=-=-=-=--=-=-=- >>> >>> Roby >>> >>> On Oct 9, 2013, at 8:12 AM, "roberto.minelli@usi.ch" roberto.minelli@usi.ch >>> wrote: >>> >>>> And yes, now the tree map builder does no longer use z-ordering to lay out the elements ;) >>>> >>>> On Oct 8, 2013, at 12:51 PM, Alexandre Bergel alexandre.bergel@me.com wrote: >>>> >>>>> Ok, excellent!!! >>>>> >>>>> Alexandre >>>>> >>>>>> Le 08-10-2013 à 6:44, "roberto.minelli@usi.ch" roberto.minelli@usi.ch a écrit : >>>>>> >>>>>> Hi, >>>>>> >>>>>> I made a couple of changes of the builder as per your suggestions. An updated usage script would be: >>>>>> >>>>>>> builder := DFTreeMapBuilder new. >>>>>>> builder weightBlock: [ :el | el ]. >>>>>>> builder nodes: (1 to: 50). >>>>>>> builder nestingFromAssociations: (builder nodes allButFirst collect: [:each | (each // 2) -> each ]). >>>>>>> >>>>>>> "Some optional configurations parameters" >>>>>>> colors := Color green mix: Color blue shades: (builder nodes size). >>>>>>> builder colorBlock: [ :el | colors at: el ]. >>>>>>> builder rootColor: ((Color red) alpha: 0.5). >>>>>>> builder inset: 5. >>>>>>> builder extent: 300@400. >>>>>>> builder origin: 10@30. >>>>>>> >>>>>>> "Some node-specific customization" >>>>>>> builder fillNodes: [ :n | (n > 40) ] withColor: (Color white). >>>>>>> builder fillNode: 50 withColor: (Color yellow). >>>>>>> builder fillNode: 43 withColor: (Color green). >>>>>>> >>>>>>> builder strokeNodes: [ :n | (n \ 2) = 1 ] withColor: (Color blue). >>>>>>> builder strokeNode: 13 withColor: (Color black). >>>>>>> >>>>>>> builder strokeNodes: [ :n | (n \ 6) = 0 ] withWidth: 2. >>>>>>> builder strokeNode: 3 withColor: (Color red). >>>>>>> builder strokeNode: 3 withWidth: 3. >>>>>>> >>>>>>> "Using the #drawOn: message for compatibility with ROMondrianViewBuilder" >>>>>>> view := ROView new. >>>>>>> view @ RODraggable. >>>>>>> builder drawOn: view. >>>>>>> view open. >>>>>> >>>>>> And the resulting tree map @ https://dl.dropboxusercontent.com/u/6281855/updated-treemap.png >>>>>> >>>>>> Now I am converting from z-ordering to nesting. Stay tuned ;) >>>>>> >>>>>> Cheers, >>>>>> Roby >>>>>> >>>>>>> On Oct 7, 2013, at 7:33 PM, Alexandre Bergel alexandre.bergel@me.com wrote: >>>>>>> >>>>>>> Looks good to me. >>>>>>> Maybe you could have in addition to >>>>>>> DFTreeMapBuilder>>associations: >>>>>>> something >>>>>>> DFTreeMapBuilder>>parent: aBlockOrASymbol >>>>>>> >>>>>>> Also, something very important that I forgot to mention, we need a method DFTreeMapBuilder>>drawOn: aROView >>>>>>> >>>>>>> Like that, we should be able to have a treemap when using the mondrian builder. Using your example, we should have exactly the same result if we do: >>>>>>> -=-=-=-=-=-=-=-=-=-=-=-= >>>>>>> builder := DFTreeMapBuilder new. >>>>>>> builder ... // your example here >>>>>>> >>>>>>> view := ROView new. >>>>>>> builder drawOn: view. >>>>>>> view open >>>>>>> -=-=-=-=-=-=-=-=-=-=-=-= >>>>>>> >>>>>>> Cheers, >>>>>>> Alexandre >>>>>>> >>>>>>> >>>>>>>> On Oct 7, 2013, at 1:07 PM, "roberto.minelli@usi.ch" roberto.minelli@usi.ch wrote: >>>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> I finished the first version of the new tree map builder for Roassal. >>>>>>>> >>>>>>>> You can find the source code in my SmalltalkHub package 'DevFlow-View'! >>>>>>>> >>>>>>>> Gofer new >>>>>>>> smalltalkhubUser: 'RobertoMinelli' project: 'DevFlow'; >>>>>>>> package: 'DevFlow-View'; >>>>>>>> load. >>>>>>>> >>>>>>>> Here's an example usage: >>>>>>>> >>>>>>>> builder := DFTreeMapBuilder new. >>>>>>>> builder weightBlock: [ :el | el ]. >>>>>>>> builder nodes: (1 to: 50). >>>>>>>> builder associations: (builder nodes allButFirst collect: [:each | (each // 2) -> each ]). >>>>>>>> >>>>>>>> "Some optional configurations parameters" >>>>>>>> colors := Color white mix: Color blue shades: (builder nodes size). >>>>>>>> builder colorBlock: [ :el | colors at: el ]. >>>>>>>> builder rootColor: ((Color red) alpha: 0.5). >>>>>>>> builder inset: 5. >>>>>>>> builder extent: 500@300. >>>>>>>> builder origin: 10@30. >>>>>>>> >>>>>>>> builder draw. >>>>>>>> >>>>>>>> And the resulting tree map! >>>>>>>> >>>>>>>> [cid:EC2669CC-CA97-4B81-8B1B-B792FBE1C04F@mobile.usilu.net] >>>>>>>> >>>>>>>> Please tell me what do you think! >>>>>>>> >>>>>>>> The next steps are: >>>>>>>> - Add customizable interactions >>>>>>>> - Remove z-ordering and use proper nesting >>>>>>>> - Eventually unroll the recursion in the layout algorithm >>>>>>>> >>>>>>>> Cheers, >>>>>>>> Roberto >>>>>>> >>>>>>> -- >>>>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>>>>> 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 >> >> >> _______________________________________________ >> 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" > > > > -- > 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
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
-- www.tudorgirba.com
"Every thing has its own flow"
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
-
Alexandre Bergel -
roberto.minelli＠usi.ch -
Tudor Girba -
Yuriy Tymchuk