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