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.
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)
You could simply multiply it. We have in the Mondrian builder:
logWidth: aBlock self width: [ :v | ((aBlock value: v) + 1) log * 10 ]
Cheers, Alexandre
nice now I'm not sure that log was a good idea :) because it changes the scale. I was stupid. Probably saying 10% less or 20% is more reasonable.
On May 28, 2013, at 3:12 PM, mathieubmddehouck@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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
As we have discussed with Mathieu today, the layout should not change the size of the node. 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@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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
On May 29, 2013, at 4:38 PM, Alexandre Bergel alexandre.bergel@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.
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@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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
On May 29, 2013, at 4:38 PM, Alexandre Bergel alexandre.bergel@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@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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: 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
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.
Cheers, Doru
On May 29, 2013, at 11:45 PM, Alexandre Bergel alexandre.bergel@me.com wrote:
On May 29, 2013, at 4:38 PM, Alexandre Bergel alexandre.bergel@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@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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: 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
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list Moose-dev@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."
On May 30, 2013, at 6:55 AM, Tudor Girba tudor@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@me.com wrote:
On May 29, 2013, at 4:38 PM, Alexandre Bergel alexandre.bergel@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@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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: 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
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list Moose-dev@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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Interesting point.
However, often by adding multiple options, you can make a script difficult to understand.
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.
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. In any case, I think we should ensure simple and transparent rules to keep scripts understandable.
Cheers, Doru
On Thu, May 30, 2013 at 9:09 AM, stephane ducasse stephane.ducasse@free.frwrote:
On May 30, 2013, at 6:55 AM, Tudor Girba tudor@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@me.com
wrote:
On May 29, 2013, at 4:38 PM, Alexandre Bergel alexandre.bergel@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@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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: 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
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list Moose-dev@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@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
On May 30, 2013, at 9:25 AM, Tudor Girba tudor@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@free.fr wrote:
On May 30, 2013, at 6:55 AM, Tudor Girba tudor@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@me.com wrote:
On May 29, 2013, at 4:38 PM, Alexandre Bergel alexandre.bergel@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@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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: 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
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list Moose-dev@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@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
Hi
Well, maybe a thing to keep in mind is that there is no implicit resizing.
You have to ask for it.
If you don't tell that you want nodes to be resize, the layout won't touch them, so basically, the layout will just move nodes.
And then, if you ask for it, the layout is able to resize the nodes following certain properties.
But it is important to think about it, because if Roassal purpose is really to work with some 5 000 nodes or more, we will soon have a problem of size, and we will need to automatically resize nodes.
Regards
Math
Hi Mathieu,
I know that you have to specify it :). All I am saying is that it would be great to have some sort of convention that alerts a user that some fancier decision is being made behind the scene when two specifications compete with each other. Perhaps having a certain name for the setting is good enough.
Is this point really so terrible?
Cheers, Doru
On Thu, May 30, 2013 at 9:59 AM, mathieubmddehouck@mailoo.org wrote:
**
Hi
Well, maybe a thing to keep in mind is that there is no implicit resizing.
You have to ask for it.
If you don't tell that you want nodes to be resize, the layout won't touch them, so basically, the layout will just move nodes.
And then, if you ask for it, the layout is able to resize the nodes following certain properties.
But it is important to think about it, because if Roassal purpose is really to work with some 5 000 nodes or more, we will soon have a problem of size, and we will need to automatically resize nodes.
Regards
Math
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
On May 30, 2013, at 10:11 AM, Tudor Girba tudor@tudorgirba.com wrote:
Hi Mathieu,
I know that you have to specify it :). All I am saying is that it would be great to have some sort of convention that alerts a user that some fancier decision is being made behind the scene when two specifications compete with each other. Perhaps having a certain name for the setting is good enough.
Is this point really so terrible?
but we take it into account
Cheers, Doru
On Thu, May 30, 2013 at 9:59 AM, mathieubmddehouck@mailoo.org wrote: Hi
Well, maybe a thing to keep in mind is that there is no implicit resizing.
You have to ask for it.
If you don't tell that you want nodes to be resize, the layout won't touch them, so basically, the layout will just move nodes.
And then, if you ask for it, the layout is able to resize the nodes following certain properties.
But it is important to think about it, because if Roassal purpose is really to work with some 5 000 nodes or more, we will soon have a problem of size, and we will need to automatically resize nodes.
Regards
Math
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
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@inria.fr
wrote:
On May 30, 2013, at 9:25 AM, Tudor Girba tudor@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@free.fr> wrote:
On May 30, 2013, at 6:55 AM, Tudor Girba tudor@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@me.com
wrote:
On May 29, 2013, at 4:38 PM, Alexandre Bergel <
alexandre.bergel@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@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@iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: 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
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list Moose-dev@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@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
So we discussed here and here are the conclusions.
- We understand (but doubt that it makes sense in general case) that layout should not change node size. So we will produce a packing without node changes but we will probably produce others with that too.
- We should encapsulate the logic of the graph fitting on the screen. Because else all the clients will duplicate this behavior.
- We will produce probably some other linearisers and see if it is working. - ShrinkingXPercentOfOutiers - Medianizer would be good.
- It would be good to be able to query a layout to know if the population can be nicely displayed with it.
- Note that the same way in codecrawler cyan was used to distinguish between zero and the minimal visual size, we could have an visual hint for large nodes that have been shrunk.
Stef
This sounds great.
Doru
-- www.tudorgirba.com
"Every thing has its own flow."
On 30.05.2013, at 13:55, Stéphane Ducasse stephane.ducasse@inria.fr wrote:
So we discussed here and here are the conclusions.
- We understand (but doubt that it makes sense in general case) that layout should not change
node size. So we will produce a packing without node changes but we will probably produce others with that too.
- We should encapsulate the logic of the graph fitting on the screen. Because else all the clients
will duplicate this behavior.
We will produce probably some other linearisers and see if it is working. - ShrinkingXPercentOfOutiers - Medianizer would be good.
It would be good to be able to query a layout to know if the population can be nicely displayed
with it.
- Note that the same way in codecrawler cyan was used to distinguish between zero and the minimal visual size, we could have an visual hint for large nodes that have been shrunk.
Stef
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
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,
I do not think that this is good to force the client to specify a specific width for packing.
What you want is either specify a ratio or a starting size or a maxium size
and the algorithm should either do not change the node size or compute the ecart-type and either apply a linear shrink or a outlier decrease.
Probably we should have PackingMaxSize PackingRatio
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@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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: 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
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
In fact thinking about it I thought that you want to have both - simple Packing algo that is totally agnotisc and where the user has to pass the right node shape and the alternative.
Stef
On May 30, 2013, at 9:05 AM, stephane ducasse stephane.ducasse@free.fr wrote:
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,
I do not think that this is good to force the client to specify a specific width for packing.
What you want is either specify a ratio or a starting size or a maxium size
and the algorithm should either do not change the node size or compute the ecart-type and either apply a linear shrink or a outlier decrease.
Probably we should have PackingMaxSize PackingRatio
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@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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: 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
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-
Alexandre Bergel -
Ben Coman -
mathieubmddehouck＠mailoo.org -
stephane ducasse -
Stéphane Ducasse -
Tudor Girba