I am looking at it now… Your text is in italic below
• Checking for empty elements collection is provided in RTLayout>>applyOn: and thus can be removed from doExecute: (e.g. from RTCircleLayout)
=> DONE. I have removed unnecessary checks. Well spotted!
• RTAbstractGridLayout>>lineItemsCount: aBlock can accept also just a number (for example in RTExample>>cellLayout2), so the name aBlock is confusing. Maybe should be renamed to aBlockOrNumber?
=> DONE. I have also commented the method
Only difference I found between RTCircleLayout and RTCenteredCirleLayout is center := Point x: rad y: rad. vs centerPoint := center.
Why do we need two classes? Why not just add center to CircleLayout and remove RTCenteredCircleLayout? It is confusing.
=> I am thinking about removing the class RTCenteredCirleLayout. Since we have groups. It does not make sense anymore. For example:
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
v := RTView new.
center := (RTEllipse new size: 8; color: Color blue) element.
v add: center.
center translateTo: 80 @ 60.
elements := (RTEllipse new size: 5; color: Color red) elementsOn: (1 to: 20).
v addAll: elements.
RTCircleLayout on: elements.
elements translateTo: 80 @ 60.
v
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
I have removed RTcenteredCircleLayout
Currently there is in RTAbstractCircleLayout both initialAngleInDegrees: aNumber and initialAngle: aFloat. It seems unnecessary to me to keep both methods; why not remove all xxxInDegress:?
=> I see your point. However it does not harm having both way to set the initial angle. It is common in API to treat degree and radian that way as far as I have seen.
RTCircleLayout translates using translateTopLeftOf:to: while RTEquidistantCircleLayoutuses translate:to:
Wouldn't it make more sense to use translate:to also for RTCircleLayout?
=> Could be. It may break tests. I think this is the reason why I did not change it as you suggested.
What is the exact difference between Equidistant and Weighted layouts?
=> Subtil here. Equidistant makes sure you have the same distance between each element. Weighted try to fill the empty space. Consider these examples:
-=-=-=-=-=-=-=-=-=-=-=-=
v := RTView new.
center := (RTEllipse new size: 8; color: Color blue) element.
v add: center.
center translateTo: 80 @ 60.
elements := (RTEllipse new size: 5; color: Color red; size: [:vv | vv * 4 ]) elementsOn: (1 to: 15).
v addAll: elements.
RTEquidistantCircleLayout on: elements.
elements translateTo: 80 @ 60.
v
-=-=-=-=-=-=-=-=-=-=-=-=
Using the Weighted circle:
v := RTView new.
center := (RTEllipse new size: 8; color: Color blue) element.
v add: center.
center translateTo: 80 @ 60.
elements := (RTEllipse new size: 5; color: Color red; size: [:vv | vv * 4 ]) elementsOn: (1 to: 15).
v addAll: elements.
RTWeightedCircleLayout on: elements.
elements translateTo: 80 @ 60.
v
Does it make sense?
Q: Why is RTHorizontalFlowLayout named horizontal, if it flows in columns from top to bottom?
=> I see your point. But here another example:
Does this make sense?
Q: Shouldn't there be protocols for left/right alignment in RTFlowLayout?
=> Pierre worked on this. I am forwarding the email to him.
Q: Why one cannot specify alignment for RTAbstractGridLayout?
=> We could do that. But the makes the code with a lot of ifTrue:ifFalse:. Things that I would like to avoid.
Bug: RTCellLayout layouting issues
=> Indeed. You’re right. I am wondering what the RTCellLayout is useful for. Juraj worked on it. I will ask him.
Q: What is the purpose / use case of stretchable in RTAbstractLineLayout?
=> This is legacy code. It was useful in Roassal 1 and Mondrian (Roassal -1 :-) where a node can nest other node. We cannot directly do this in Roassal2. Instead, the stretchable should be in TRConstraint I think. Or maybe the stretchable should take a width (as a numerical value, or a block) as parameter.
Q: RTTreeLayout - Doubled lines?
=> I am not able to reproduce it.
Apparently the method is missing (although you are using it ?). I have committed it.
RTLayoutBuilder>>dominanceTree
actionOnEdges add: [ :edge | edge shape withVerticallAttachPoint ].
layout := RTDominanceTreeLayout new.
^ layout
Bug: RTRoassalExample>>exampleSmoothLayout
=> Fixed! The class RODummyNode was missing, I have added it and renamed it into RTDummyNode
Cool example isn’t it?
RTRoassalExample new exampleSmoothLayout
Bug: RTLabelled
=> I do not understand this. Or Maybe I understand. Are you referring to:
-=-=-=-=-=-=-=-=-=
v := RTView new.
e := (RTEllipse new size: 40) elementOn: 'Happiness'.
v add: e.
e @ RTLabelled.
v
-=-=-=-=-=-=-=-=-=
vs
-=-=-=-=-=-=-=-=-=
v := RTView new.
e @ RTLabelled.
e := (RTEllipse new size: 40) elementOn: 'Happiness'.
v add: e.
v
-=-=-=-=-=-=-=-=-=
You need to add an element to the view before adding a label to it. The reason is that RTLabelled add a label trachel shape above the trachel shape of the element. However, if the element has not been added to the view, then there is no trachel shape.
Thanks Peter for this great discussion! Thanks for looking into the core of Roassal. This is important!
Cheers,
Alexandre
On Mar 19, 2015, at 7:03 PM, Peter Uhnák <i.uhnak@gmail.com> wrote:
Hi Alex,
did you have any chance to look at the revised questions?
Peter
On Fri, Mar 13, 2015 at 7:30 PM, Peter Uhnák <i.uhnak@gmail.com> wrote:
Hi Alex,
The connectFrom: [ :value | value // 3 ] , in this case, create edges you probably do not want to have. Such has 0 -> 0. Apparently the layout cannot handle this. Would be great to fix this by the way.
aha, that make sense; thanks
I have to say I did not understand much about the other questions.
Sorry I wrote that as sidenotes without much context.
I've rewritten it https://gist.github.com/peteruhnak/b62c776bcb93dedb849b so it should be much more understandable.
- you put the script to execute in the chapter
Yes, I'll change this.
Peter
_______________________________________________
Moose-dev mailing list
Moose-dev@iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel
http://www.bergel.eu^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.