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