7 Oct
2013
7 Oct
'13
6:07 p.m.
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
7 Oct
7 Oct
7:33 p.m.
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(a)usi.ch"
<roberto.minelli(a)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
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
8 Oct
8 Oct
11:44 a.m.
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(a)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(a)usi.ch"
<roberto.minelli(a)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
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
12:51 p.m.
Ok, excellent!!!
Alexandre
Le 08-10-2013 à 6:44,
"roberto.minelli(a)usi.ch" <roberto.minelli(a)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(a)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(a)usi.ch" <roberto.minelli(a)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
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
9 Oct
9 Oct
8:12 a.m.
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(a)me.com> wrote:
Ok, excellent!!!
Alexandre
> Le 08-10-2013 à 6:44, "roberto.minelli(a)usi.ch"
<roberto.minelli(a)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(a)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(a)usi.ch"
<roberto.minelli(a)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
>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>
9:30 a.m.
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(a)usi.ch"
<roberto.minelli(a)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(a)me.com> wrote:
Ok, excellent!!!
Alexandre
> Le 08-10-2013 à 6:44, "roberto.minelli(a)usi.ch"
<roberto.minelli(a)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(a)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(a)usi.ch"
<roberto.minelli(a)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(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev 
9:57 a.m.
404 on dropbox
On Oct 9, 2013, at 9:30 AM, roberto.minelli(a)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(a)usi.ch"
<roberto.minelli(a)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(a)me.com> wrote:
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev Ok, excellent!!!
Alexandre
> Le 08-10-2013 à 6:44, "roberto.minelli(a)usi.ch"
<roberto.minelli(a)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(a)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(a)usi.ch"
<roberto.minelli(a)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(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
10:02 a.m.
Sorry, DropBox messed up the image name. I updated the file ;)
On Oct 9, 2013, at 9:57 AM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote:
404 on dropbox
On Oct 9, 2013, at 9:30 AM, roberto.minelli(a)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(a)usi.ch"
<roberto.minelli(a)usi.ch>
wrote:
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev 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(a)me.com> wrote:
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev Ok, excellent!!!
Alexandre
> Le 08-10-2013 à 6:44, "roberto.minelli(a)usi.ch"
<roberto.minelli(a)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(a)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(a)usi.ch"
<roberto.minelli(a)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(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev 
10:11 a.m.
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(a)usi.ch <
roberto.minelli(a)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(a)me.com> wrote:
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
www.tudorgirba.com
"Every thing has its own flow"
404 on dropbox
On Oct 9, 2013, at 9:30 AM, roberto.minelli(a)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(a)usi.ch" <
roberto.minelli(a)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(a)me.com>
wrote:
>>
>>> Ok, excellent!!!
>>>
>>> Alexandre
>>>
>>>> Le 08-10-2013 à 6:44, "roberto.minelli(a)usi.ch" <
roberto.minelli(a)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(a)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(a)usi.ch"
<
roberto.minelli(a)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(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
10:47 a.m.
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(a)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(a)usi.ch <
roberto.minelli(a)usi.ch> wrote:
--
www.tudorgirba.com
"Every thing has its own flow"
Sorry, DropBox messed up the image name. I
updated the file ;)
On Oct 9, 2013, at 9:57 AM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote:
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
www.tudorgirba.com
"Every thing has its own flow"
404 on dropbox
On Oct 9, 2013, at 9:30 AM, roberto.minelli(a)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(a)usi.ch" <
roberto.minelli(a)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(a)me.com> wrote:
>>
>>> Ok, excellent!!!
>>>
>>> Alexandre
>>>
>>>> Le 08-10-2013 à 6:44, "roberto.minelli(a)usi.ch" <
roberto.minelli(a)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(a)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(a)usi.ch"
<
roberto.minelli(a)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(a)iam.unibe.ch
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
11:28 a.m.
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(a)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(a)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(a)usi.ch <roberto.minelli(a)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(a)me.com> wrote:
404 on dropbox
On Oct 9, 2013, at 9:30 AM, roberto.minelli(a)usi.ch wrote:
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
www.tudorgirba.com
"Every thing has its own flow"
--
www.tudorgirba.com
"Every thing has its own flow"
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev 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(a)usi.ch"
<roberto.minelli(a)usi.ch>
wrote:
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev 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(a)me.com> wrote:
> Ok, excellent!!!
>
> Alexandre
>
>> Le 08-10-2013 à 6:44, "roberto.minelli(a)usi.ch"
<roberto.minelli(a)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(a)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(a)usi.ch"
<roberto.minelli(a)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(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
11:43 a.m.
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(a)usi.ch"
<roberto.minelli(a)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(a)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(a)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(a)usi.ch <roberto.minelli(a)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(a)me.com> wrote:
_______________________________________________
Moose-dev mailing list
Moose-dev(a)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(a)usi.ch wrote:
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
www.tudorgirba.com
"Every thing has its own flow"
--
www.tudorgirba.com
"Every thing has its own flow"
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev 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(a)usi.ch"
<roberto.minelli(a)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(a)me.com> wrote:
>
>> Ok, excellent!!!
>>
>> Alexandre
>>
>>> Le 08-10-2013 à 6:44, "roberto.minelli(a)usi.ch"
<roberto.minelli(a)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(a)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(a)usi.ch"
<roberto.minelli(a)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(a)iam.unibe.ch
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
9:31 p.m.
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(a)usi.ch <
roberto.minelli(a)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(a)usi.ch" <
roberto.minelli(a)usi.ch>
wrote:
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
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(a)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(a)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(a)usi.ch <
roberto.minelli(a)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(a)me.com> wrote:
>
>> 404 on dropbox
>>
>> On Oct 9, 2013, at 9:30 AM, roberto.minelli(a)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(a)usi.ch" <
roberto.minelli(a)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(a)me.com> wrote:
>>>>
>>>>> Ok, excellent!!!
>>>>>
>>>>> Alexandre
>>>>>
>>>>>> Le 08-10-2013 à 6:44, "roberto.minelli(a)usi.ch" <
roberto.minelli(a)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(a)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(a)usi.ch" <
roberto.minelli(a)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(a)iam.unibe.ch
>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>
>
> _______________________________________________
> Moose-dev mailing list
> Moose-dev(a)iam.unibe.ch
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
www.tudorgirba.com
"Every thing has its own flow"
--
www.tudorgirba.com
"Every thing has its own flow"
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
10:28 p.m.
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(a)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(a)usi.ch <roberto.minelli(a)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(a)usi.ch"
<roberto.minelli(a)usi.ch>
wrote:
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
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(a)tudorgirba.com> wrote:
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
www.tudorgirba.com
"Every thing has its own flow"
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev 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(a)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(a)usi.ch <roberto.minelli(a)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(a)me.com> wrote:
_______________________________________________
Moose-dev mailing list
Moose-dev(a)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(a)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(a)usi.ch"
<roberto.minelli(a)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(a)me.com>
wrote:
>>
>>> Ok, excellent!!!
>>>
>>> Alexandre
>>>
>>>> Le 08-10-2013 à 6:44, "roberto.minelli(a)usi.ch"
<roberto.minelli(a)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(a)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(a)usi.ch"
<roberto.minelli(a)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(a)iam.unibe.ch
>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>
>
> _______________________________________________
> Moose-dev mailing list
> Moose-dev(a)iam.unibe.ch
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
www.tudorgirba.com
"Every thing has its own flow"
--
www.tudorgirba.com
"Every thing has its own flow"
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
10 Oct
10 Oct
8:26 a.m.
On Oct 9, 2013, at 9:31 PM, Tudor Girba <tudor(a)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(a)usi.ch <roberto.minelli(a)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(a)usi.ch"
<roberto.minelli(a)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(a)tudorgirba.com> wrote:
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
www.tudorgirba.com
"Every thing has its own flow"
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev 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(a)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(a)usi.ch <roberto.minelli(a)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(a)me.com> wrote:
_______________________________________________
Moose-dev mailing list
Moose-dev(a)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(a)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(a)usi.ch"
<roberto.minelli(a)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(a)me.com>
wrote:
>>
>>> Ok, excellent!!!
>>>
>>> Alexandre
>>>
>>>> Le 08-10-2013 à 6:44, "roberto.minelli(a)usi.ch"
<roberto.minelli(a)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(a)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(a)usi.ch"
<roberto.minelli(a)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(a)iam.unibe.ch
>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>
>
> _______________________________________________
> Moose-dev mailing list
> Moose-dev(a)iam.unibe.ch
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
www.tudorgirba.com
"Every thing has its own flow"
--
www.tudorgirba.com
"Every thing has its own flow"
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
10:49 p.m.
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(a)usi.ch wrote:
On Oct 9, 2013, at 9:31 PM, Tudor Girba <tudor(a)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(a)usi.ch <roberto.minelli(a)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(a)usi.ch"
<roberto.minelli(a)usi.ch>
wrote:
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev 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(a)tudorgirba.com> wrote:
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
www.tudorgirba.com
"Every thing has its own flow"
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev 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(a)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(a)usi.ch <roberto.minelli(a)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(a)me.com> wrote:
> 404 on dropbox
>
> On Oct 9, 2013, at 9:30 AM, roberto.minelli(a)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(a)usi.ch"
<roberto.minelli(a)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(a)me.com>
wrote:
>>>
>>>> Ok, excellent!!!
>>>>
>>>> Alexandre
>>>>
>>>>> Le 08-10-2013 à 6:44, "roberto.minelli(a)usi.ch"
<roberto.minelli(a)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(a)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(a)usi.ch" <roberto.minelli(a)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(a)iam.unibe.ch
>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>
>>
>> _______________________________________________
>> Moose-dev mailing list
>> Moose-dev(a)iam.unibe.ch
>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>
>
> _______________________________________________
> Moose-dev mailing list
> Moose-dev(a)iam.unibe.ch
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
www.tudorgirba.com
"Every thing has its own flow"
--
www.tudorgirba.com
"Every thing has its own flow"
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
11 Oct
11 Oct
8:42 a.m.
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(a)usi.ch <
roberto.minelli(a)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(a)usi.ch wrote:
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
www.tudorgirba.com
"Every thing has its own flow"
On Oct 9, 2013, at 9:31 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote:
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.
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
Oh, I see. I will probably switch to the color normalizer then!
>
> Doru
>
>
>
> On Wed, Oct 9, 2013 at 11:43 AM, roberto.minelli(a)usi.ch <
roberto.minelli(a)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(a)usi.ch" <
roberto.minelli(a)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(a)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(a)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(a)usi.ch <
roberto.minelli(a)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(a)me.com>
wrote:
>>>
>>>> 404 on dropbox
>>>>
>>>> On Oct 9, 2013, at 9:30 AM, roberto.minelli(a)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(a)usi.ch" <
roberto.minelli(a)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(a)me.com> wrote:
>>>>>>
>>>>>>> Ok, excellent!!!
>>>>>>>
>>>>>>> Alexandre
>>>>>>>
>>>>>>>> Le 08-10-2013 à 6:44, "roberto.minelli(a)usi.ch"
<
roberto.minelli(a)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(a)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(a)usi.ch" <
roberto.minelli(a)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(a)iam.unibe.ch
>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>
>>>
>>> _______________________________________________
>>> Moose-dev mailing list
>>> Moose-dev(a)iam.unibe.ch
>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>
>>
>> _______________________________________________
>> Moose-dev mailing list
>> Moose-dev(a)iam.unibe.ch
>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>
>
> _______________________________________________
> Moose-dev mailing list
> Moose-dev(a)iam.unibe.ch
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>
>
>
> --
> www.tudorgirba.com
>
> "Every thing has its own flow"
>
>
>
> --
> www.tudorgirba.com
>
> "Every thing has its own flow"
> _______________________________________________
> Moose-dev mailing list
> Moose-dev(a)iam.unibe.ch
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
www.tudorgirba.com
"Every thing has its own flow"
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
1:44 p.m.
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(a)usi.ch <roberto.minelli(a)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(a)usi.ch wrote:
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
On Oct 9, 2013, at 9:31 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote:
--
www.tudorgirba.com
"Every thing has its own flow" 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(a)usi.ch <roberto.minelli(a)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(a)usi.ch"
<roberto.minelli(a)usi.ch>
wrote:
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev 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(a)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(a)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(a)usi.ch
<roberto.minelli(a)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(a)me.com> wrote:
>
>> 404 on dropbox
>>
>> On Oct 9, 2013, at 9:30 AM, roberto.minelli(a)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(a)usi.ch"
<roberto.minelli(a)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(a)me.com> wrote:
>>>>
>>>>> Ok, excellent!!!
>>>>>
>>>>> Alexandre
>>>>>
>>>>>> Le 08-10-2013 à 6:44, "roberto.minelli(a)usi.ch"
<roberto.minelli(a)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(a)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(a)usi.ch" <roberto.minelli(a)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(a)iam.unibe.ch
>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>
>>>
>>> _______________________________________________
>>> Moose-dev mailing list
>>> Moose-dev(a)iam.unibe.ch
>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>
>>
>> _______________________________________________
>> Moose-dev mailing list
>> Moose-dev(a)iam.unibe.ch
>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>
>
> _______________________________________________
> Moose-dev mailing list
> Moose-dev(a)iam.unibe.ch
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>
>
>
> --
> www.tudorgirba.com
>
> "Every thing has its own flow"
>
>
>
> --
> www.tudorgirba.com
>
> "Every thing has its own flow"
> _______________________________________________
> Moose-dev mailing list
> Moose-dev(a)iam.unibe.ch
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
www.tudorgirba.com
"Every thing has its own flow"
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
1:52 p.m.
On Oct 11, 2013, at 1:44 PM, Alexandre Bergel <alexandre.bergel(a)me.com>
wrote:
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 ;)
Great!
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
Cheers,
Roby
On Thu, Oct 10, 2013 at 10:49 PM, roberto.minelli(a)usi.ch <roberto.minelli(a)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(a)usi.ch wrote:
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
On Oct 9, 2013, at 9:31 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote:
--
www.tudorgirba.com
"Every thing has its own flow" 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(a)usi.ch <roberto.minelli(a)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(a)usi.ch"
<roberto.minelli(a)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(a)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(a)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(a)usi.ch
<roberto.minelli(a)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(a)me.com> wrote:
>>
>>> 404 on dropbox
>>>
>>> On Oct 9, 2013, at 9:30 AM, roberto.minelli(a)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(a)usi.ch"
<roberto.minelli(a)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(a)me.com> wrote:
>>>>>
>>>>>> Ok, excellent!!!
>>>>>>
>>>>>> Alexandre
>>>>>>
>>>>>>> Le 08-10-2013 à 6:44, "roberto.minelli(a)usi.ch"
<roberto.minelli(a)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(a)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(a)usi.ch" <roberto.minelli(a)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(a)iam.unibe.ch
>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>>
>>>>
>>>> _______________________________________________
>>>> Moose-dev mailing list
>>>> Moose-dev(a)iam.unibe.ch
>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>
>>>
>>> _______________________________________________
>>> Moose-dev mailing list
>>> Moose-dev(a)iam.unibe.ch
>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>
>>
>> _______________________________________________
>> Moose-dev mailing list
>> Moose-dev(a)iam.unibe.ch
>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>
>>
>>
>> --
>> www.tudorgirba.com
>>
>> "Every thing has its own flow"
>>
>>
>>
>> --
>> www.tudorgirba.com
>>
>> "Every thing has its own flow"
>> _______________________________________________
>> Moose-dev mailing list
>> Moose-dev(a)iam.unibe.ch
>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>
>
> _______________________________________________
> Moose-dev mailing list
> Moose-dev(a)iam.unibe.ch
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
www.tudorgirba.com
"Every thing has its own flow"
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
12 Oct
12 Oct
4:28 a.m.
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(a)usi.ch wrote:
On Oct 11, 2013, at 1:44 PM, Alexandre Bergel
<alexandre.bergel(a)me.com>
wrote:
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 ;)
Great!
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
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
Cheers,
Roby
On Thu, Oct 10, 2013 at 10:49 PM, roberto.minelli(a)usi.ch <roberto.minelli(a)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(a)usi.ch wrote:
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
On Oct 9, 2013, at 9:31 PM, Tudor Girba <tudor(a)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(a)usi.ch
<roberto.minelli(a)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(a)usi.ch"
<roberto.minelli(a)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(a)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(a)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(a)usi.ch
<roberto.minelli(a)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(a)me.com>
wrote:
>>>
>>>> 404 on dropbox
>>>>
>>>> On Oct 9, 2013, at 9:30 AM, roberto.minelli(a)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(a)usi.ch"
<roberto.minelli(a)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(a)me.com> wrote:
>>>>>>
>>>>>>> Ok, excellent!!!
>>>>>>>
>>>>>>> Alexandre
>>>>>>>
>>>>>>>> Le 08-10-2013 à 6:44, "roberto.minelli(a)usi.ch"
<roberto.minelli(a)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(a)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(a)usi.ch" <roberto.minelli(a)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(a)iam.unibe.ch
>>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Moose-dev mailing list
>>>>> Moose-dev(a)iam.unibe.ch
>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>>
>>>>
>>>> _______________________________________________
>>>> Moose-dev mailing list
>>>> Moose-dev(a)iam.unibe.ch
>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>
>>>
>>> _______________________________________________
>>> Moose-dev mailing list
>>> Moose-dev(a)iam.unibe.ch
>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>
>>>
>>>
>>> --
>>> www.tudorgirba.com
>>>
>>> "Every thing has its own flow"
>>>
>>>
>>>
>>> --
>>> www.tudorgirba.com
>>>
>>> "Every thing has its own flow"
>>> _______________________________________________
>>> Moose-dev mailing list
>>> Moose-dev(a)iam.unibe.ch
>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>
>>
>> _______________________________________________
>> Moose-dev mailing list
>> Moose-dev(a)iam.unibe.ch
>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>
>
> _______________________________________________
> Moose-dev mailing list
> Moose-dev(a)iam.unibe.ch
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>
>
>
> --
> www.tudorgirba.com
>
> "Every thing has its own flow"
> _______________________________________________
> Moose-dev mailing list
> Moose-dev(a)iam.unibe.ch
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
www.tudorgirba.com
"Every thing has its own flow"
4136
days inactive
4141
days old
19 comments
4 participants
participants (4)
-
Alexandre Bergel -
roberto.minelli＠usi.ch -
Tudor Girba -
Yuriy Tymchuk