30 May
2013
30 May
'13
9:42 a.m.
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.
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:
--
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 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