Hi Stef,
I do not understand your tone. I am not unhappy at all.
I was just talking about a concern I have. It might be completely
irrelevant or even wrong, but it is a concern I have. So, I am raising it.
Please let's just continue to work as a team that can happen to have
divergent opinions (which in this case, it's not even that much of the
case).
I will reply to the technical details separately.
Cheers,
Doru
On Thu, May 30, 2013 at 9:42 AM, Stéphane Ducasse <stephane.ducasse(a)inria.fr
wrote:
>
> On May 30, 2013, at 9:25 AM, Tudor Girba <tudor(a)tudorgirba.com
wrote:
>
> Interesting point.
>
> However, often by adding multiple options, you can make a script difficult
> to understand.
>
>
> My goal is not understanding this is having at hand the right tool.
> Examples and documentation are for that. Or we should just do addition and
> multiplication but no more.
>
When you need to make a significant decision fast on which a larger project
depends, you will care about the trace-ability of your reasoning. I was
several times in this situation, and if I got to doubt
> One significant problem when building a representation, is to ensure that
> what it shows is what you think it shows (ha, I just coined my own
> abbreviation: WISIWYTIS :)). This is particularly important in scenarios in
> which we take only 15 minutes to look at a piece of data.
>
>
> If you have nested packing boxes then you should not use the local
> recomputation of the node size
> because you would lose the overall comparison (this is why I say that we
> should have one that
> is neutral) but when you have one
>
> In addition we should be able to pass the parameter from one packing to
> the other so that
> we can pack with smoothing and get the same smooth.
>
> Of course the client that take the responsibility to compute an ecrattype
> and apply an exponential or a linear
> transformation. For my layout are not limited to node positions.
>
> Imagine you have the nodes defining their own size, and at the same time
> we have the layout that makes a decision about size. Simply by looking at
> the picture you will not know whether it shows what you expect simply
> without knowing exactly what decisions have been made by the underlying
> engine. The only way you will know if by inspecting each shape and see if
> it matches the node size, and not the implicit sizing algorithm.
>
> I am not sure I made my point clear.
>
>
> Yes this is why we should pay attention to log and other manipulation.
>
> Now if there is a couple of boxes that fuck up your visualization and as
> such you
> tool and in this turn your end-user and clients then being able to take
> reasonable actions is important.
>
>
> In any case, I think we should ensure simple and transparent rules to keep
> scripts understandable.
>
>
> I hate the term script. We write programs.
>
> Now if what we are doing is not worth let us know. We can also create our
> own layouts and do not share them.
> I can also avoid to pay guys to work on roassal or to work on our own
> packages.
> Because if having two variability points on packing (which is one
> difficult algorithm) does not make happy
> moosers we will not bother you with that.
>
> Stef
>
>
> Cheers,
> Doru
>
>
>
>
> On Thu, May 30, 2013 at 9:09 AM, stephane ducasse <
> stephane.ducasse(a)free.fr
wrote:
>
>>
>> On May 30, 2013, at 6:55 AM, Tudor Girba <tudor(a)tudorgirba.com
wrote:
>>
>> > I agree.
>> >
>> > We want to keep to a minimum the amount of hardcoded decisions in the
>> engine. In this case, the solution proposed by Alex is just fine while
>> still keeping the layout generic and applicable to various cases.
>>
>>
>> but in that case we lose logic. I think that logic should not be in
>> clients. We should have objects that naturally
>> embed it.
>>
>> Your approach works but for simple layout. Packing is probably one of the
>> most difficult one
>> since you have two dimensions and outliers.
>> >
>> > Cheers,
>> > Doru
>> >
>> >
>> > On May 29, 2013, at 11:45 PM, Alexandre Bergel
<alexandre.bergel(a)me.com>
>
wrote:
>> >
>> >>> On May 29, 2013, at 4:38 PM, Alexandre Bergel <
>> alexandre.bergel(a)me.com
wrote:
>>
>>>
>> >>>> As we have discussed with Mathieu today, the layout should not
>> change the size of the node.
>> >>>
>> >>> why?
>> >>> Because I spent one hour with him trying to find way to reduce the
>> size of the largest node
>> >>> if necessary. nd not using log because log is too strong.
>> >>
>> >> The function of the layout is to locate nodes. As soon as a layout has
>> to change the size of a node, this means that you do not want to use the
>> Mondrian builder, but instead create your own builder. In your case, I
>> think you need to adjust the shape from the script, and not from the
>> layout. For example, Mathieu's code is
>> >>
>> >> -=-=-=-=-=-=-=-=-=-=-=-=
>> >> b := 30.
>> >> view shape rectangle
>> >> width: [ :cls | cls numberOfVariables * 5 ];
>> >> height: #numberOfMethods;
>> >> color: (Color r: 0 g: 1 b: 1 ).
>> >> view nodes: TestCase withAllSubclasses.
>> >> view nodes do: [ :e | (e width > b ) ifTrue: [ e shapes first color:
>> (Color r: 1 g: 0 b: 1 ) ] ].
>> >> view layout:(( RORectanglePacking new)ratioWidth: 10 height: 10;
>> padding: 4; logWidthIfMoreThan: b scale: 5).
>> >> -=-=-=-=-=-=-=-=-=-=-=-=
>> >>
>> >> It could simply be:
>> >>
>> >> -=-=-=-=-=-=-=-=-=-=-=-=
>> >> view shape rectangle
>> >> width: [ :cls | (cls numberOfVariables + 1) log * 30 ];
>> >> height: #numberOfMethods;
>> >> color: (Color r: 0 g: 1 b: 1 );
>> >> if: [ :cls | cls numberOfVariables > 10 ] fillColor: (Color r:
1
>> g: 0 b: 1) .
>> >>
>> >> view nodes: TestCase withAllSubclasses.
>> >> view layout: (( RORectanglePacking new) ratioWidth: 10 height: 10;
>> padding: 4).
>> >> -=-=-=-=-=-=-=-=-=-=-=-=
>> >>
>> >>
>> >>
>> >> Cheers,
>> >> Alexandre
>> >>
>> >>>
>> >>>
>> >>>> If this is necessary, then a new builder is necessary. We are
>> currently working on two new builder (one for DSMs and another for
>> Sunburst).
>> >>>>
>> >>>> Alexandre
>> >>>>
>> >>>>
>> >>>> On May 28, 2013, at 9:12 AM, mathieubmddehouck(a)mailoo.org
wrote:
>> >>>>
>> >>>>> Hi
>> >>>>>
>> >>>>>
>> >>>>> I've fixed a big on ROArc, so that it draws well.
>> >>>>>
>> >>>>> And I've commented and added methods to
RORectanglePacking to
>> reduce biggest nodes, and so on.
>> >>>>>
>> >>>>>
>> >>>>> try:
>> >>>>>
>> >>>>>
>> >>>>> Gofer new
>> >>>>> smalltalkhubUser: 'MathieuDehouck' project:
'RoassalAlgorithm';
>> >>>>> package: 'Roassal-New';
>> >>>>> load
>> >>>>>
>> >>>>>
>> >>>>> | view rawView n b |
>> >>>>> rawView := ROView new.
>> >>>>> view := ROMondrianViewBuilder view: rawView.
>> >>>>> "-------------"
>> >>>>> "-------------"
>> >>>>> b := 30.
>> >>>>>
>> >>>>> view shape rectangle
>> >>>>> width: [ :cls | cls numberOfVariables * 5 ];
>> >>>>> height: #numberOfMethods;
>> >>>>> color: (Color r: 0 g: 1 b: 1 ).
>> >>>>>
>> >>>>> view nodes: TestCase withAllSubclasses.
>> >>>>>
>> >>>>> view nodes do: [ :e | (e width > b ) ifTrue: [ e shapes
first
>> color: (Color r: 1 g: 0 b: 1 ) ] ].
>> >>>>>
>> >>>>>
>> >>>>> view layout:(( RORectanglePacking new)ratioWidth: 10 height:
10;
>> padding: 4; logWidthIfMoreThan: b scale: 5).
>> >>>>>
>> >>>>> "-------------"
>> >>>>> "-------------"
>> >>>>> "Below is the initiation of the menu and opening the
visualization"
>> >>>>> ROEaselMorphic new populateMenuOn: view.
>> >>>>> view open.
>> >>>>>
>> >>>>>
>> >>>>> There are other log... methods, and scale represent the
factor to
>> multiply the logs by. (yes log 10 = 1 and that's pretty small in pixel)
>> >>>>>
>> >>>>> Regards
>> >>>>>
>> >>>>> Mathieu
>> >>>>>
>> >>>>>
>> >>>>> P.S. The screens have been made with the width and the
height in
>> the same time.
>> >>>>>
>> >>>>>
>> >>>>> <RECT TestCase log 30.png><Rect
>> after.png>_______________________________________________
>> >>>>> Moose-dev mailing list
>> >>>>> Moose-dev(a)iam.unibe.ch
>> >>>>>
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>> >>>>
>> >>>> --
>> >>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
>> >>>> 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
>> >>
>> >> --
>> >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
>> >> 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
>> >
>> > --
>> >
www.tudorgirba.com
>> >
>> > "If you interrupt the barber while he is cutting your hair,
>> > you will end up with a messy haircut."
>> >
>> >
>> > _______________________________________________
>> > 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"