Hi!
I’ve just introduced a new class TRExtensibleLabelShape and TRLabelShape. This will ease the problem we are experiencing with using labels in a composed shape.
I would like now to discuss about how to compose shapes. This has been a big discussion for at least 5 years. I propose a solution in this email, I hope this will make most of us happy :-)
Consider the example:
-=-=-=-=-=-=-=-= | v s1 s2 c es | v := RTView new.
s1 := (RTEllipse new size: #yourself; color: (Color blue alpha: 0.4)). s2 := (RTLabel new text: 'Hello World'; height: 10).
c := RTCompositeShape new shape1: s1; shape2: s2; offset2: 0 @ -30.
es := c elementsOn: #(30 60 80). es @ RTDraggable. v addAll: es.
es when: TRMouseClick do: [ :evt | evt element remove. v signalUpdate ].
RTHorizontalLineLayout on: v elements. v open -=-=-=-=-=-=-=-=
This is the output:
If you click on an element, then the element with its label is properly removed. Yupi! Leo will be happy with that :-) The reason is that how can I specify to have s2 above s1? What should I put in offset2 ? Instead of fiddling with blocks like [:shape1 :shape2 :element | … ] I have introduced RTHorizontalCompositeShape and RTVerticalCompositeShape just to try whether it make sense or not.
We can have -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= | v s1 s2 c es | v := RTView new.
s1 := (RTEllipse new size: #yourself; color: (Color blue alpha: 0.4)). s2 := (RTLabel new text: 'Hello World'; height: 10).
c := RTHorizontalCompositeShape new shape1: s1; shape2: s2.
es := c elementsOn: #(30 60 80). es @ RTDraggable. v addAll: es.
RTHorizontalLineLayout on: v elements. v -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Replacing Horizontal by Vertical works as expected.
You can also compose these things. Look at that: -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= | v s1 s2 c es | v := RTView new.
s1 := (RTEllipse new size: #yourself; color: (Color blue alpha: 0.4)). s2 := (RTLabel new text: 'Hello World'; height: 10).
c2 := RTVerticalCompositeShape new shape1: s1; shape2: s2. c := RTHorizontalCompositeShape new shape1: s1; shape2: c2.
es := c elementsOn: #(30 60 80). es @ RTDraggable. v addAll: es.
RTHorizontalLineLayout on: v elements. v -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Are we happy with RTVerticalCompositeShape, RTHorizontalCompositeShape and RTCompositeShape ?
If yes, then RTLabelling (and its problem of passing the view along :-) will be obsolete.
Cheers, Alexandre
As I use a lot of CompositeShape in my project I will give you a lot of feedbacks ;-) I like the composition of composite shape itself. I needed it now it will so much easier.
But is it possible the put a RTCompositeShape as fixed ? Let me give you an example to show you I'm working on a Menu in my vizualisation so i want them fix. But a menu is a label and its "background' so a composite shape. Can I set it as fixed ?
On Thu, Apr 24, 2014 at 3:39 PM, Alexandre Bergel alexandre.bergel@me.comwrote:
Hi!
I’ve just introduced a new class TRExtensibleLabelShape and TRLabelShape. This will ease the problem we are experiencing with using labels in a composed shape.
I would like now to discuss about how to compose shapes. This has been a big discussion for at least 5 years. I propose a solution in this email, I hope this will make most of us happy :-)
Consider the example:
-=-=-=-=-=-=-=-= | v s1 s2 c es | v := RTView new.
s1 := (RTEllipse new size: #yourself; color: (Color blue alpha: 0.4)). s2 := (RTLabel new text: 'Hello World'; height: 10).
c := RTCompositeShape new shape1: s1; shape2: s2; offset2: 0 @ -30.
es := c elementsOn: #(30 60 80). es @ RTDraggable. v addAll: es.
es when: TRMouseClick do: [ :evt | evt element remove. v signalUpdate ].
RTHorizontalLineLayout on: v elements. v open -=-=-=-=-=-=-=-=
This is the output:
If you click on an element, then the element with its label is properly removed. Yupi! Leo will be happy with that :-) The reason is that how can I specify to have s2 above s1? What should I put in offset2 ? Instead of fiddling with blocks like [:shape1 :shape2 :element | … ] I have introduced RTHorizontalCompositeShape and RTVerticalCompositeShape just to try whether it make sense or not.
We can have
| v s1 s2 c es | v := RTView new.
s1 := (RTEllipse new size: #yourself; color: (Color blue alpha: 0.4)). s2 := (RTLabel new text: 'Hello World'; height: 10).
c := RTHorizontalCompositeShape new shape1: s1; shape2: s2.
es := c elementsOn: #(30 60 80). es @ RTDraggable. v addAll: es.
RTHorizontalLineLayout on: v elements. v -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Replacing Horizontal by Vertical works as expected.
You can also compose these things. Look at that:
| v s1 s2 c es | v := RTView new.
s1 := (RTEllipse new size: #yourself; color: (Color blue alpha: 0.4)). s2 := (RTLabel new text: 'Hello World'; height: 10).
c2 := RTVerticalCompositeShape new shape1: s1; shape2: s2. c := RTHorizontalCompositeShape new shape1: s1; shape2: c2.
es := c elementsOn: #(30 60 80). es @ RTDraggable. v addAll: es.
RTHorizontalLineLayout on: v elements. v -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Are we happy with RTVerticalCompositeShape, RTHorizontalCompositeShape and RTCompositeShape ?
If yes, then RTLabelling (and its problem of passing the view along :-) will be obsolete.
Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
I just committed the possibility for element to be fixed or not.
For example:
testAdding
| e1 e2 | e1 := RTBox element. e2 := RTBox element. e1 setAsFixed. view add: e1. view add: e2. self assert: view canvas numberOfFixedShapes = 1. self assert: view canvas numberOfShapes = 1.
Let me know whether this works as you expect.
Cheers, Alexandre
On Thu, Apr 24, 2014 at 5:12 PM, Alexandre Bergel alexandre.bergel@me.comwrote:
I just committed the possibility for element to be fixed or not.
For example:
testAdding
| e1 e2 | e1 := RTBox element. e2 := RTBox element. e1 setAsFixed. view add: e1. view add: e2. self assert: view canvas numberOfFixedShapes = 1. self assert: view canvas numberOfShapes = 1.Let me know whether this works as you expect.
No I get this error :
The canvas of the composite shape is nil
-- Leo Perard
There is a bug when I update an element which has a RTCompositeShape with one of its shape as a RTCompositeShape too
On Thu, Apr 24, 2014 at 5:29 PM, Leo Perard leo.perard@gmail.com wrote:
On Thu, Apr 24, 2014 at 5:12 PM, Alexandre Bergel <alexandre.bergel@me.com
wrote:
I just committed the possibility for element to be fixed or not.
For example:
testAdding
| e1 e2 | e1 := RTBox element. e2 := RTBox element. e1 setAsFixed. view add: e1. view add: e2. self assert: view canvas numberOfFixedShapes = 1. self assert: view canvas numberOfShapes = 1.Let me know whether this works as you expect.
No I get this error :
The canvas of the composite shape is nil
-- Leo Perard
How can I reproduce this bug? What do you do exactly?
Alexandre
On Apr 24, 2014, at 1:07 PM, Leo Perard leo.perard@gmail.com wrote:
There is a bug when I update an element which has a RTCompositeShape with one of its shape as a RTCompositeShape too
<update-composite-shape.png>
On Thu, Apr 24, 2014 at 5:29 PM, Leo Perard leo.perard@gmail.com wrote: On Thu, Apr 24, 2014 at 5:12 PM, Alexandre Bergel alexandre.bergel@me.com wrote: I just committed the possibility for element to be fixed or not.
For example:
testAdding
| e1 e2 | e1 := RTBox element. e2 := RTBox element. e1 setAsFixed. view add: e1. view add: e2. self assert: view canvas numberOfFixedShapes = 1. self assert: view canvas numberOfShapes = 1.Let me know whether this works as you expect.
No I get this error : <error-setAsFixed.png>
The canvas of the composite shape is nil
-- Leo Perard
-- Leo Perard _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
On Thu, Apr 24, 2014 at 10:00 PM, Alexandre Bergel alexandre.bergel@me.comwrote:
How can I reproduce this bug? What do you do exactly?
With this example you can reproduce it easily :
view := RTView new. box := RTBox new color: Color green. label := RTLabel new. el := (RTCompositeShape new shape1: box; shape2: label). el := (RTHorizontalCompositeShape new shape1: el; shape2: (RTEllipse new color: Color red)) elementOn: 'Hello World'. view add: el.
view addMenu: 'Color' callback: [ el shape shape2 color: Color blue. el update. view signalUpdate ].
view open
And even if I don't have a composite shape composed with another composite shape, the update is not good.
Hi!
I’ve worked a bit on the composition. So far, we have three ways to compose shapes:
1 - RTCompositeShape. This is the composition that is used with +
-=-=-=-=-=-=-=-=-=-= | v s1 s2 e | v := RTView new. s1 := RTBox new size: #yourself; color: Color blue. s2 := RTEllipse new size: [ :value | value / 2 ]; color: Color red. e := (RTCompositeShape with: s1 with: s2) elementOn: 50. v add: e. v -=-=-=-=-=-=-=-=-=-=
2 - RTHorizontalCompositeShape Here is the effect of replacing RTCompositeShape by RTHorizontalCompositeShape in the previous example
3 - RTVerticalCompositeShape
All the shapes composed with RTCompositeShape have the same size. This is useful for example if you do: (RTBox new + RTLabel) elementOn: ‘Hello World’. You typically want the label and the box have the same size. When you want to line up shapes, I guess you do not care of having all the shapes of the same size.
This new behavior for horizontal and vertical should address what you need Leo.
The nice thing, in my opinion, is that we should be able to have any kind of strategy, for example, a grid of shapes. This is really a matter of small programming.
Let me know if this is what you expect. Just update Roassal for this.
Cheers, Alexandre
On Apr 25, 2014, at 5:55 AM, Leo Perard leo.perard@gmail.com wrote:
On Thu, Apr 24, 2014 at 10:00 PM, Alexandre Bergel alexandre.bergel@me.com wrote: How can I reproduce this bug? What do you do exactly? With this example you can reproduce it easily :
view := RTView new. box := RTBox new color: Color green. label := RTLabel new. el := (RTCompositeShape new shape1: box; shape2: label). el := (RTHorizontalCompositeShape new shape1: el; shape2: (RTEllipse new color: Color red)) elementOn: 'Hello World'. view add: el.
view addMenu: 'Color' callback: [ el shape shape2 color: Color blue. el update. view signalUpdate ].
view open
And even if I don't have a composite shape composed with another composite shape, the update is not good.
Leo Perard _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Hi Alex,
This starts to look good.
The next thing is to specify where nested children go :). For example, I would want to be able to specify that the nested children should be in the blue rectangle. For this, we would probably need something in the direction of a ChildrenShape :). Also, the other challenge is to not let the RTNest make the decision of where to place the children.
What do you say?
Doru
On Sun, Apr 27, 2014 at 9:37 PM, Alexandre Bergel alexandre.bergel@me.comwrote:
Hi!
I’ve worked a bit on the composition. So far, we have three ways to compose shapes:
1 - RTCompositeShape. This is the composition that is used with +
-=-=-=-=-=-=-=-=-=-= | v s1 s2 e | v := RTView new. s1 := RTBox new size: #yourself; color: Color blue. s2 := RTEllipse new size: [ :value | value / 2 ]; color: Color red. e := (RTCompositeShape with: s1 with: s2) elementOn: 50. v add: e. v -=-=-=-=-=-=-=-=-=-=
2 - RTHorizontalCompositeShape Here is the effect of replacing RTCompositeShape by RTHorizontalCompositeShape in the previous example
3 - RTVerticalCompositeShape
All the shapes composed with RTCompositeShape have the same size. This is useful for example if you do: (RTBox new + RTLabel) elementOn: ‘Hello World’. You typically want the label and the box have the same size. When you want to line up shapes, I guess you do not care of having all the shapes of the same size.
This new behavior for horizontal and vertical should address what you need Leo.
The nice thing, in my opinion, is that we should be able to have any kind of strategy, for example, a grid of shapes. This is really a matter of small programming.
Let me know if this is what you expect. Just update Roassal for this.
Cheers, Alexandre
On Apr 25, 2014, at 5:55 AM, Leo Perard leo.perard@gmail.com wrote:
On Thu, Apr 24, 2014 at 10:00 PM, Alexandre Bergel < alexandre.bergel@me.com> wrote: How can I reproduce this bug? What do you do exactly? With this example you can reproduce it easily :
view := RTView new. box := RTBox new color: Color green. label := RTLabel new. el := (RTCompositeShape new shape1: box; shape2: label). el := (RTHorizontalCompositeShape new shape1: el; shape2: (RTEllipse new color: Color red)) elementOn: 'Hello World'. view add: el.
view addMenu: 'Color' callback: [ el shape shape2 color: Color blue. el update. view signalUpdate ].
view open
And even if I don't have a composite shape composed with another composite shape, the update is not good. -- Leo Perard _______________________________________________ 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
Question : Why need a special shape to composite shapes together and not do it like Morphic where each morph acts also as a container for other Morphs ? I also like the fact that a morph can have not only children but also a parent.
On Sun, Apr 27, 2014 at 10:59 PM, Tudor Girba tudor@tudorgirba.com wrote:
Hi Alex,
This starts to look good.
The next thing is to specify where nested children go :). For example, I would want to be able to specify that the nested children should be in the blue rectangle. For this, we would probably need something in the direction of a ChildrenShape :). Also, the other challenge is to not let the RTNest make the decision of where to place the children.
What do you say?
Doru
On Sun, Apr 27, 2014 at 9:37 PM, Alexandre Bergel <alexandre.bergel@me.com
wrote:
Hi!
I’ve worked a bit on the composition. So far, we have three ways to compose shapes:
1 - RTCompositeShape. This is the composition that is used with +
-=-=-=-=-=-=-=-=-=-= | v s1 s2 e | v := RTView new. s1 := RTBox new size: #yourself; color: Color blue. s2 := RTEllipse new size: [ :value | value / 2 ]; color: Color red. e := (RTCompositeShape with: s1 with: s2) elementOn: 50. v add: e. v -=-=-=-=-=-=-=-=-=-=
2 - RTHorizontalCompositeShape Here is the effect of replacing RTCompositeShape by RTHorizontalCompositeShape in the previous example
3 - RTVerticalCompositeShape
All the shapes composed with RTCompositeShape have the same size. This is useful for example if you do: (RTBox new + RTLabel) elementOn: ‘Hello World’. You typically want the label and the box have the same size. When you want to line up shapes, I guess you do not care of having all the shapes of the same size.
This new behavior for horizontal and vertical should address what you need Leo.
The nice thing, in my opinion, is that we should be able to have any kind of strategy, for example, a grid of shapes. This is really a matter of small programming.
Let me know if this is what you expect. Just update Roassal for this.
Cheers, Alexandre
On Apr 25, 2014, at 5:55 AM, Leo Perard leo.perard@gmail.com wrote:
On Thu, Apr 24, 2014 at 10:00 PM, Alexandre Bergel < alexandre.bergel@me.com> wrote: How can I reproduce this bug? What do you do exactly? With this example you can reproduce it easily :
view := RTView new. box := RTBox new color: Color green. label := RTLabel new. el := (RTCompositeShape new shape1: box; shape2: label). el := (RTHorizontalCompositeShape new shape1: el; shape2: (RTEllipse new color: Color red)) elementOn: 'Hello World'. view add: el.
view addMenu: 'Color' callback: [ el shape shape2 color: Color blue. el update. view signalUpdate ].
view open
And even if I don't have a composite shape composed with another composite shape, the update is not good. -- Leo Perard _______________________________________________ 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
"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 Kilon,
Question : Why need a special shape to composite shapes together and not do it like Morphic where each morph acts also as a container for other Morphs ? I also like the fact that a morph can have not only children but also a parent.
Over the year, I got convinced that having an element a container is a bad idea. Having containment is a complex thing. Horribly complex. If you have containment, you will then face the following situations: - dragging inner elements. What happens when an inner element reaches the border of the container? Should it extend the container? Push it? Or simply be stopped? - What do you do with event? Should you propagate events to the parent if the children has no callback? - If you want to structure your object differently, let’s say using a quad tree, what do you do with the nesting relationship? - What do you do with edges that crosses depth (e.g., going from a top level element to an inner element)? How do you order edges? Using a z-order I guess… again more complexity
Answering all these questions (as I did with Roassal1), inevitably brings complexity to the whole system. Roassal2 does not have containment, and the root of the element and shape hierarchy is quite small, which was not the case for Roassal1 and Mondrian.
I have been thinking a lot (really a lot) about this.
Cheers, Alexandre
On Sun, Apr 27, 2014 at 10:59 PM, Tudor Girba tudor@tudorgirba.com wrote: Hi Alex,
This starts to look good.
The next thing is to specify where nested children go :). For example, I would want to be able to specify that the nested children should be in the blue rectangle. For this, we would probably need something in the direction of a ChildrenShape :). Also, the other challenge is to not let the RTNest make the decision of where to place the children.
What do you say?
Doru
On Sun, Apr 27, 2014 at 9:37 PM, Alexandre Bergel alexandre.bergel@me.com wrote: Hi!
I’ve worked a bit on the composition. So far, we have three ways to compose shapes:
1 - RTCompositeShape. This is the composition that is used with +
-=-=-=-=-=-=-=-=-=-= | v s1 s2 e | v := RTView new. s1 := RTBox new size: #yourself; color: Color blue. s2 := RTEllipse new size: [ :value | value / 2 ]; color: Color red. e := (RTCompositeShape with: s1 with: s2) elementOn: 50. v add: e. v -=-=-=-=-=-=-=-=-=-= <Screen Shot 2014-04-27 at 4.30.40 PM.png>
2 - RTHorizontalCompositeShape Here is the effect of replacing RTCompositeShape by RTHorizontalCompositeShape in the previous example <Screen Shot 2014-04-27 at 4.33.32 PM.png>
3 - RTVerticalCompositeShape <Screen Shot 2014-04-27 at 4.33.52 PM.png>
All the shapes composed with RTCompositeShape have the same size. This is useful for example if you do: (RTBox new + RTLabel) elementOn: ‘Hello World’. You typically want the label and the box have the same size. When you want to line up shapes, I guess you do not care of having all the shapes of the same size.
This new behavior for horizontal and vertical should address what you need Leo.
The nice thing, in my opinion, is that we should be able to have any kind of strategy, for example, a grid of shapes. This is really a matter of small programming.
Let me know if this is what you expect. Just update Roassal for this.
Cheers, Alexandre
On Apr 25, 2014, at 5:55 AM, Leo Perard leo.perard@gmail.com wrote:
On Thu, Apr 24, 2014 at 10:00 PM, Alexandre Bergel alexandre.bergel@me.com wrote: How can I reproduce this bug? What do you do exactly? With this example you can reproduce it easily :
view := RTView new. box := RTBox new color: Color green. label := RTLabel new. el := (RTCompositeShape new shape1: box; shape2: label). el := (RTHorizontalCompositeShape new shape1: el; shape2: (RTEllipse new color: Color red)) elementOn: 'Hello World'. view add: el.
view addMenu: 'Color' callback: [ el shape shape2 color: Color blue. el update. view signalUpdate ].
view open
And even if I don't have a composite shape composed with another composite shape, the update is not good.
Leo Perard _______________________________________________ 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
"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
I am not against your philosophy on this, but that would not mean a different class for every different kind of problem you will try to solve in composition ? Wont this make the system more complex for the user , having to use a different class for a different kind of composition ?
On Tue, Apr 29, 2014 at 3:01 AM, Alexandre Bergel alexandre.bergel@me.comwrote:
Hi Kilon,
Question : Why need a special shape to composite shapes together and not
do it like Morphic where each morph acts also as a container for other Morphs ? I also like the fact that a morph can have not only children but also a parent.
Over the year, I got convinced that having an element a container is a bad idea. Having containment is a complex thing. Horribly complex. If you have containment, you will then face the following situations: - dragging inner elements. What happens when an inner element reaches the border of the container? Should it extend the container? Push it? Or simply be stopped? - What do you do with event? Should you propagate events to the parent if the children has no callback? - If you want to structure your object differently, let’s say using a quad tree, what do you do with the nesting relationship? - What do you do with edges that crosses depth (e.g., going from a top level element to an inner element)? How do you order edges? Using a z-order I guess… again more complexity
Answering all these questions (as I did with Roassal1), inevitably brings complexity to the whole system. Roassal2 does not have containment, and the root of the element and shape hierarchy is quite small, which was not the case for Roassal1 and Mondrian.
I have been thinking a lot (really a lot) about this.
Cheers, Alexandre
On Sun, Apr 27, 2014 at 10:59 PM, Tudor Girba tudor@tudorgirba.com
wrote:
Hi Alex,
This starts to look good.
The next thing is to specify where nested children go :). For example, I
would want to be able to specify that the nested children should be in the blue rectangle. For this, we would probably need something in the direction of a ChildrenShape :). Also, the other challenge is to not let the RTNest make the decision of where to place the children.
What do you say?
Doru
On Sun, Apr 27, 2014 at 9:37 PM, Alexandre Bergel <
alexandre.bergel@me.com> wrote:
Hi!
I’ve worked a bit on the composition. So far, we have three ways to compose shapes:
1 - RTCompositeShape. This is the composition that is used with +
-=-=-=-=-=-=-=-=-=-= | v s1 s2 e | v := RTView new. s1 := RTBox new size: #yourself; color: Color blue. s2 := RTEllipse new size: [ :value | value / 2 ]; color: Color red. e := (RTCompositeShape with: s1 with: s2) elementOn: 50. v add: e. v -=-=-=-=-=-=-=-=-=-= <Screen Shot 2014-04-27 at 4.30.40 PM.png>
2 - RTHorizontalCompositeShape Here is the effect of replacing RTCompositeShape by
RTHorizontalCompositeShape in the previous example
<Screen Shot 2014-04-27 at 4.33.32 PM.png>
3 - RTVerticalCompositeShape <Screen Shot 2014-04-27 at 4.33.52 PM.png>
All the shapes composed with RTCompositeShape have the same size. This
is useful for example if you do: (RTBox new + RTLabel) elementOn: ‘Hello World’. You typically want the label and the box have the same size. When you want to line up shapes, I guess you do not care of having all the shapes of the same size.
This new behavior for horizontal and vertical should address what you
need Leo.
The nice thing, in my opinion, is that we should be able to have any
kind of strategy, for example, a grid of shapes. This is really a matter of small programming.
Let me know if this is what you expect. Just update Roassal for this.
Cheers, Alexandre
On Apr 25, 2014, at 5:55 AM, Leo Perard leo.perard@gmail.com wrote:
On Thu, Apr 24, 2014 at 10:00 PM, Alexandre Bergel <
alexandre.bergel@me.com> wrote:
How can I reproduce this bug? What do you do exactly? With this example you can reproduce it easily :
view := RTView new. box := RTBox new color: Color green. label := RTLabel new. el := (RTCompositeShape new shape1: box; shape2: label). el := (RTHorizontalCompositeShape new shape1: el; shape2: (RTEllipse
new color: Color red)) elementOn: 'Hello World'.
view add: el.
view addMenu: 'Color' callback: [ el shape shape2 color: Color blue. el
update. view signalUpdate ].
view open
And even if I don't have a composite shape composed with another
composite shape, the update is not good.
-- Leo Perard _______________________________________________ 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
"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
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
I am not against your philosophy on this, but that would not mean a different class for every different kind of problem you will try to solve in composition ? Wont this make the system more complex for the user , having to use a different class for a different kind of composition ?
Yes, one class per family of problem to solve. I do not think this will make it more complex. The situation could be worse: having one method per family of problem, and all the method in the same class. You end up with an overly complex system.
Alexandre
On Tue, Apr 29, 2014 at 3:01 AM, Alexandre Bergel alexandre.bergel@me.com wrote: Hi Kilon,
Question : Why need a special shape to composite shapes together and not do it like Morphic where each morph acts also as a container for other Morphs ? I also like the fact that a morph can have not only children but also a parent.
Over the year, I got convinced that having an element a container is a bad idea. Having containment is a complex thing. Horribly complex. If you have containment, you will then face the following situations: - dragging inner elements. What happens when an inner element reaches the border of the container? Should it extend the container? Push it? Or simply be stopped? - What do you do with event? Should you propagate events to the parent if the children has no callback? - If you want to structure your object differently, let’s say using a quad tree, what do you do with the nesting relationship? - What do you do with edges that crosses depth (e.g., going from a top level element to an inner element)? How do you order edges? Using a z-order I guess… again more complexity
Answering all these questions (as I did with Roassal1), inevitably brings complexity to the whole system. Roassal2 does not have containment, and the root of the element and shape hierarchy is quite small, which was not the case for Roassal1 and Mondrian.
I have been thinking a lot (really a lot) about this.
Cheers, Alexandre
On Sun, Apr 27, 2014 at 10:59 PM, Tudor Girba tudor@tudorgirba.com wrote: Hi Alex,
This starts to look good.
The next thing is to specify where nested children go :). For example, I would want to be able to specify that the nested children should be in the blue rectangle. For this, we would probably need something in the direction of a ChildrenShape :). Also, the other challenge is to not let the RTNest make the decision of where to place the children.
What do you say?
Doru
On Sun, Apr 27, 2014 at 9:37 PM, Alexandre Bergel alexandre.bergel@me.com wrote: Hi!
I’ve worked a bit on the composition. So far, we have three ways to compose shapes:
1 - RTCompositeShape. This is the composition that is used with +
-=-=-=-=-=-=-=-=-=-= | v s1 s2 e | v := RTView new. s1 := RTBox new size: #yourself; color: Color blue. s2 := RTEllipse new size: [ :value | value / 2 ]; color: Color red. e := (RTCompositeShape with: s1 with: s2) elementOn: 50. v add: e. v -=-=-=-=-=-=-=-=-=-= <Screen Shot 2014-04-27 at 4.30.40 PM.png>
2 - RTHorizontalCompositeShape Here is the effect of replacing RTCompositeShape by RTHorizontalCompositeShape in the previous example <Screen Shot 2014-04-27 at 4.33.32 PM.png>
3 - RTVerticalCompositeShape <Screen Shot 2014-04-27 at 4.33.52 PM.png>
All the shapes composed with RTCompositeShape have the same size. This is useful for example if you do: (RTBox new + RTLabel) elementOn: ‘Hello World’. You typically want the label and the box have the same size. When you want to line up shapes, I guess you do not care of having all the shapes of the same size.
This new behavior for horizontal and vertical should address what you need Leo.
The nice thing, in my opinion, is that we should be able to have any kind of strategy, for example, a grid of shapes. This is really a matter of small programming.
Let me know if this is what you expect. Just update Roassal for this.
Cheers, Alexandre
On Apr 25, 2014, at 5:55 AM, Leo Perard leo.perard@gmail.com wrote:
On Thu, Apr 24, 2014 at 10:00 PM, Alexandre Bergel alexandre.bergel@me.com wrote: How can I reproduce this bug? What do you do exactly? With this example you can reproduce it easily :
view := RTView new. box := RTBox new color: Color green. label := RTLabel new. el := (RTCompositeShape new shape1: box; shape2: label). el := (RTHorizontalCompositeShape new shape1: el; shape2: (RTEllipse new color: Color red)) elementOn: 'Hello World'. view add: el.
view addMenu: 'Color' callback: [ el shape shape2 color: Color blue. el update. view signalUpdate ].
view open
And even if I don't have a composite shape composed with another composite shape, the update is not good.
Leo Perard _______________________________________________ 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
"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
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: 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
fair enough. Please carry on, I find the discussion very interesting and I really like what you have done with Roassal. Is this going to carry to Mondrian as well ?
On Tue, Apr 29, 2014 at 12:49 PM, Alexandre Bergel alexandre.bergel@me.comwrote:
I am not against your philosophy on this, but that would not mean a
different class for every different kind of problem you will try to solve in composition ? Wont this make the system more complex for the user , having to use a different class for a different kind of composition ?
Yes, one class per family of problem to solve. I do not think this will make it more complex. The situation could be worse: having one method per family of problem, and all the method in the same class. You end up with an overly complex system.
Alexandre
On Tue, Apr 29, 2014 at 3:01 AM, Alexandre Bergel <
alexandre.bergel@me.com> wrote:
Hi Kilon,
Question : Why need a special shape to composite shapes together and
not do it like Morphic where each morph acts also as a container for other Morphs ? I also like the fact that a morph can have not only children but also a parent.
Over the year, I got convinced that having an element a container is a
bad idea. Having containment is a complex thing. Horribly complex.
If you have containment, you will then face the following situations: - dragging inner elements. What happens when an inner element
reaches the border of the container? Should it extend the container? Push it? Or simply be stopped?
- What do you do with event? Should you propagate events to theparent if the children has no callback?
- If you want to structure your object differently, let’s sayusing a quad tree, what do you do with the nesting relationship?
- What do you do with edges that crosses depth (e.g., going froma top level element to an inner element)? How do you order edges? Using a z-order I guess… again more complexity
Answering all these questions (as I did with Roassal1), inevitably
brings complexity to the whole system.
Roassal2 does not have containment, and the root of the element and
shape hierarchy is quite small, which was not the case for Roassal1 and Mondrian.
I have been thinking a lot (really a lot) about this.
Cheers, Alexandre
On Sun, Apr 27, 2014 at 10:59 PM, Tudor Girba tudor@tudorgirba.com
wrote:
Hi Alex,
This starts to look good.
The next thing is to specify where nested children go :). For example,
I would want to be able to specify that the nested children should be in the blue rectangle. For this, we would probably need something in the direction of a ChildrenShape :). Also, the other challenge is to not let the RTNest make the decision of where to place the children.
What do you say?
Doru
On Sun, Apr 27, 2014 at 9:37 PM, Alexandre Bergel <
alexandre.bergel@me.com> wrote:
Hi!
I’ve worked a bit on the composition. So far, we have three ways to compose shapes:
1 - RTCompositeShape. This is the composition that is used with +
-=-=-=-=-=-=-=-=-=-= | v s1 s2 e | v := RTView new. s1 := RTBox new size: #yourself; color: Color blue. s2 := RTEllipse new size: [ :value | value / 2 ]; color: Color red. e := (RTCompositeShape with: s1 with: s2) elementOn: 50. v add: e. v -=-=-=-=-=-=-=-=-=-= <Screen Shot 2014-04-27 at 4.30.40 PM.png>
2 - RTHorizontalCompositeShape Here is the effect of replacing RTCompositeShape by
RTHorizontalCompositeShape in the previous example
<Screen Shot 2014-04-27 at 4.33.32 PM.png>
3 - RTVerticalCompositeShape <Screen Shot 2014-04-27 at 4.33.52 PM.png>
All the shapes composed with RTCompositeShape have the same size. This
is useful for example if you do: (RTBox new + RTLabel) elementOn: ‘Hello World’. You typically want the label and the box have the same size. When you want to line up shapes, I guess you do not care of having all the shapes of the same size.
This new behavior for horizontal and vertical should address what you
need Leo.
The nice thing, in my opinion, is that we should be able to have any
kind of strategy, for example, a grid of shapes. This is really a matter of small programming.
Let me know if this is what you expect. Just update Roassal for this.
Cheers, Alexandre
On Apr 25, 2014, at 5:55 AM, Leo Perard leo.perard@gmail.com wrote:
On Thu, Apr 24, 2014 at 10:00 PM, Alexandre Bergel <
alexandre.bergel@me.com> wrote:
How can I reproduce this bug? What do you do exactly? With this example you can reproduce it easily :
view := RTView new. box := RTBox new color: Color green. label := RTLabel new. el := (RTCompositeShape new shape1: box; shape2: label). el := (RTHorizontalCompositeShape new shape1: el; shape2: (RTEllipse
new color: Color red)) elementOn: 'Hello World'.
view add: el.
view addMenu: 'Color' callback: [ el shape shape2 color: Color blue.
el update. view signalUpdate ].
view open
And even if I don't have a composite shape composed with another
composite shape, the update is not good.
-- Leo Perard _______________________________________________ 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
"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
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: 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
Is this going to carry to Mondrian as well ?
I do not understand this question :-) Roassal has a Mondrian builder in it, the class RTMondrianViewBuilder…
Alexandre
I mean whether this way of composition of shapes will be also available to Mondrian.
The way I understand it so far, is that Mondrian is a higher level library based on Roassal. It can do things that Roassal can in fewer steps focusing on visualization of object structures. So as Roassal needs to deal with complex shapes so does Mondrian. Am I correct ?
Do you mean that RTMondrianViewBuilder already acts as the compositor of complex shapes for Mondrian ? If yes that means that Mondrian will not be affected by these improvements ?
On Tue, Apr 29, 2014 at 1:07 PM, Alexandre Bergel alexandre.bergel@me.comwrote:
Is this going to carry to Mondrian as well ?
I do not understand this question :-) Roassal has a Mondrian builder in it, the class RTMondrianViewBuilder…
Alexandre
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
I mean whether this way of composition of shapes will be also available to Mondrian.
Could be. We have to see. Mondrian is (really) good only for a restricted set of situations.
The way I understand it so far, is that Mondrian is a higher level library based on Roassal. It can do things that Roassal can in fewer steps focusing on visualization of object structures. So as Roassal needs to deal with complex shapes so does Mondrian. Am I correct ?
Yes, making Roassal things available in Mondrian is not a big deal.
Do you mean that RTMondrianViewBuilder already acts as the compositor of complex shapes for Mondrian ? If yes that means that Mondrian will not be affected by these improvements ?
The class RTMondrianViewBuilder is simply a builder (i.e., generate low Roassal instruction from a specification tied to a particular model). It does not compose shapes, but instead generates elements with shapes (as all the builder do).
Alexandre
On Tue, Apr 29, 2014 at 1:07 PM, Alexandre Bergel alexandre.bergel@me.com wrote:
Is this going to carry to Mondrian as well ?
I do not understand this question :-) Roassal has a Mondrian builder in it, the class RTMondrianViewBuilder…
Alexandre
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: 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
Great excatly the kind of thing I expected.
I'm agree with Tudor, the nested element on a CompositeElement are really not great now. I maked some tests last weeks but no one was working.
On Sun, Apr 27, 2014 at 9:59 PM, Tudor Girba tudor@tudorgirba.com wrote:
Hi Alex,
This starts to look good.
The next thing is to specify where nested children go :). For example, I would want to be able to specify that the nested children should be in the blue rectangle. For this, we would probably need something in the direction of a ChildrenShape :). Also, the other challenge is to not let the RTNest make the decision of where to place the children.
What do you say?
Doru
On Sun, Apr 27, 2014 at 9:37 PM, Alexandre Bergel <alexandre.bergel@me.com
wrote:
Hi!
I’ve worked a bit on the composition. So far, we have three ways to compose shapes:
1 - RTCompositeShape. This is the composition that is used with +
-=-=-=-=-=-=-=-=-=-= | v s1 s2 e | v := RTView new. s1 := RTBox new size: #yourself; color: Color blue. s2 := RTEllipse new size: [ :value | value / 2 ]; color: Color red. e := (RTCompositeShape with: s1 with: s2) elementOn: 50. v add: e. v -=-=-=-=-=-=-=-=-=-=
2 - RTHorizontalCompositeShape Here is the effect of replacing RTCompositeShape by RTHorizontalCompositeShape in the previous example
3 - RTVerticalCompositeShape
All the shapes composed with RTCompositeShape have the same size. This is useful for example if you do: (RTBox new + RTLabel) elementOn: ‘Hello World’. You typically want the label and the box have the same size. When you want to line up shapes, I guess you do not care of having all the shapes of the same size.
This new behavior for horizontal and vertical should address what you need Leo.
The nice thing, in my opinion, is that we should be able to have any kind of strategy, for example, a grid of shapes. This is really a matter of small programming.
Let me know if this is what you expect. Just update Roassal for this.
Cheers, Alexandre
On Apr 25, 2014, at 5:55 AM, Leo Perard leo.perard@gmail.com wrote:
On Thu, Apr 24, 2014 at 10:00 PM, Alexandre Bergel < alexandre.bergel@me.com> wrote: How can I reproduce this bug? What do you do exactly? With this example you can reproduce it easily :
view := RTView new. box := RTBox new color: Color green. label := RTLabel new. el := (RTCompositeShape new shape1: box; shape2: label). el := (RTHorizontalCompositeShape new shape1: el; shape2: (RTEllipse new color: Color red)) elementOn: 'Hello World'. view add: el.
view addMenu: 'Color' callback: [ el shape shape2 color: Color blue. el update. view signalUpdate ].
view open
And even if I don't have a composite shape composed with another composite shape, the update is not good. -- Leo Perard _______________________________________________ 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
"Every thing has its own flow"
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Leo, can you provide an example of what was not working?
Alexandre
Le 28-04-2014 à 5:26, Leo Perard leo.perard@gmail.com a écrit :
Great excatly the kind of thing I expected.
I'm agree with Tudor, the nested element on a CompositeElement are really not great now. I maked some tests last weeks but no one was working.
On Sun, Apr 27, 2014 at 9:59 PM, Tudor Girba tudor@tudorgirba.com wrote: Hi Alex,
This starts to look good.
The next thing is to specify where nested children go :). For example, I would want to be able to specify that the nested children should be in the blue rectangle. For this, we would probably need something in the direction of a ChildrenShape :). Also, the other challenge is to not let the RTNest make the decision of where to place the children.
What do you say?
Doru
On Sun, Apr 27, 2014 at 9:37 PM, Alexandre Bergel alexandre.bergel@me.com wrote: Hi!
I’ve worked a bit on the composition. So far, we have three ways to compose shapes:
1 - RTCompositeShape. This is the composition that is used with +
-=-=-=-=-=-=-=-=-=-= | v s1 s2 e | v := RTView new. s1 := RTBox new size: #yourself; color: Color blue. s2 := RTEllipse new size: [ :value | value / 2 ]; color: Color red. e := (RTCompositeShape with: s1 with: s2) elementOn: 50. v add: e. v -=-=-=-=-=-=-=-=-=-= <Screen Shot 2014-04-27 at 4.30.40 PM.png>
2 - RTHorizontalCompositeShape Here is the effect of replacing RTCompositeShape by RTHorizontalCompositeShape in the previous example <Screen Shot 2014-04-27 at 4.33.32 PM.png>
3 - RTVerticalCompositeShape <Screen Shot 2014-04-27 at 4.33.52 PM.png>
All the shapes composed with RTCompositeShape have the same size. This is useful for example if you do: (RTBox new + RTLabel) elementOn: ‘Hello World’. You typically want the label and the box have the same size. When you want to line up shapes, I guess you do not care of having all the shapes of the same size.
This new behavior for horizontal and vertical should address what you need Leo.
The nice thing, in my opinion, is that we should be able to have any kind of strategy, for example, a grid of shapes. This is really a matter of small programming.
Let me know if this is what you expect. Just update Roassal for this.
Cheers, Alexandre
On Apr 25, 2014, at 5:55 AM, Leo Perard leo.perard@gmail.com wrote:
On Thu, Apr 24, 2014 at 10:00 PM, Alexandre Bergel alexandre.bergel@me.com wrote: How can I reproduce this bug? What do you do exactly? With this example you can reproduce it easily :
view := RTView new. box := RTBox new color: Color green. label := RTLabel new. el := (RTCompositeShape new shape1: box; shape2: label). el := (RTHorizontalCompositeShape new shape1: el; shape2: (RTEllipse new color: Color red)) elementOn: 'Hello World'. view add: el.
view addMenu: 'Color' callback: [ el shape shape2 color: Color blue. el update. view signalUpdate ].
view open
And even if I don't have a composite shape composed with another composite shape, the update is not good.
Leo Perard _______________________________________________ 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
"Every thing has its own flow"
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- Leo Perard _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Sure.
view := RTView new.
container := (RTHorizontalCompositeShape new shape1: RTBox new; shape2: RTLabel new) elementOn: 'Container'. els := (RTBox new size: 9; color: Color red) elementsOn: (1 to: 16). container @ RTDraggable.
RTNest new layout: RTGridLayout; on: container nest: els. view add: container; addAll: els. view open
I tried to "cheat" with the order of the calls. I nested the els just with the box and then I created a composite shape with + but no success.
view := RTView new.
container := RTBox new elementOn: 'Container'. els := (RTBox new size: 9; color: Color red) elementsOn: (1 to: 16). RTNest new layout: RTGridLayout; on: container nest: els. container + RTLabel. container @ RTDraggable.
view add: container; addAll: els. view open
On Mon, Apr 28, 2014 at 12:09 PM, Alexandre Bergel alexandre.bergel@me.comwrote:
Leo, can you provide an example of what was not working?
Alexandre
Le 28-04-2014 à 5:26, Leo Perard leo.perard@gmail.com a écrit :
Great excatly the kind of thing I expected.
I'm agree with Tudor, the nested element on a CompositeElement are really not great now. I maked some tests last weeks but no one was working.
On Sun, Apr 27, 2014 at 9:59 PM, Tudor Girba tudor@tudorgirba.com wrote:
Hi Alex,
This starts to look good.
The next thing is to specify where nested children go :). For example, I would want to be able to specify that the nested children should be in the blue rectangle. For this, we would probably need something in the direction of a ChildrenShape :). Also, the other challenge is to not let the RTNest make the decision of where to place the children.
What do you say?
Doru
On Sun, Apr 27, 2014 at 9:37 PM, Alexandre Bergel < alexandre.bergel@me.com> wrote:
Hi!
I’ve worked a bit on the composition. So far, we have three ways to compose shapes:
1 - RTCompositeShape. This is the composition that is used with +
-=-=-=-=-=-=-=-=-=-= | v s1 s2 e | v := RTView new. s1 := RTBox new size: #yourself; color: Color blue. s2 := RTEllipse new size: [ :value | value / 2 ]; color: Color red. e := (RTCompositeShape with: s1 with: s2) elementOn: 50. v add: e. v -=-=-=-=-=-=-=-=-=-= <Screen Shot 2014-04-27 at 4.30.40 PM.png>
2 - RTHorizontalCompositeShape Here is the effect of replacing RTCompositeShape by RTHorizontalCompositeShape in the previous example <Screen Shot 2014-04-27 at 4.33.32 PM.png>
3 - RTVerticalCompositeShape <Screen Shot 2014-04-27 at 4.33.52 PM.png>
All the shapes composed with RTCompositeShape have the same size. This is useful for example if you do: (RTBox new + RTLabel) elementOn: ‘Hello World’. You typically want the label and the box have the same size. When you want to line up shapes, I guess you do not care of having all the shapes of the same size.
This new behavior for horizontal and vertical should address what you need Leo.
The nice thing, in my opinion, is that we should be able to have any kind of strategy, for example, a grid of shapes. This is really a matter of small programming.
Let me know if this is what you expect. Just update Roassal for this.
Cheers, Alexandre
On Apr 25, 2014, at 5:55 AM, Leo Perard leo.perard@gmail.com wrote:
On Thu, Apr 24, 2014 at 10:00 PM, Alexandre Bergel < alexandre.bergel@me.com> wrote: How can I reproduce this bug? What do you do exactly? With this example you can reproduce it easily :
view := RTView new. box := RTBox new color: Color green. label := RTLabel new. el := (RTCompositeShape new shape1: box; shape2: label). el := (RTHorizontalCompositeShape new shape1: el; shape2: (RTEllipse new color: Color red)) elementOn: 'Hello World'. view add: el.
view addMenu: 'Color' callback: [ el shape shape2 color: Color blue. el update. view signalUpdate ].
view open
And even if I don't have a composite shape composed with another composite shape, the update is not good. -- Leo Perard _______________________________________________ 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
"Every thing has its own flow"
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- Leo Perard
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 have the impression you need to manually build your composed shape, with a dedicated builder (i.e., subclass of RTBuilder).
What are you trying to achieve?
Alexandre
On Apr 28, 2014, at 8:08 AM, Leo Perard leo.perard@gmail.com wrote:
Sure.
view := RTView new.
container := (RTHorizontalCompositeShape new shape1: RTBox new; shape2: RTLabel new) elementOn: 'Container'. els := (RTBox new size: 9; color: Color red) elementsOn: (1 to: 16). container @ RTDraggable.
RTNest new layout: RTGridLayout; on: container nest: els. view add: container; addAll: els. view open
I tried to "cheat" with the order of the calls. I nested the els just with the box and then I created a composite shape with + but no success.
view := RTView new.
container := RTBox new elementOn: 'Container'. els := (RTBox new size: 9; color: Color red) elementsOn: (1 to: 16). RTNest new layout: RTGridLayout; on: container nest: els. container + RTLabel. container @ RTDraggable.
view add: container; addAll: els. view open
On Mon, Apr 28, 2014 at 12:09 PM, Alexandre Bergel alexandre.bergel@me.com wrote: Leo, can you provide an example of what was not working?
Alexandre
Le 28-04-2014 à 5:26, Leo Perard leo.perard@gmail.com a écrit :
Great excatly the kind of thing I expected.
I'm agree with Tudor, the nested element on a CompositeElement are really not great now. I maked some tests last weeks but no one was working.
On Sun, Apr 27, 2014 at 9:59 PM, Tudor Girba tudor@tudorgirba.com wrote: Hi Alex,
This starts to look good.
The next thing is to specify where nested children go :). For example, I would want to be able to specify that the nested children should be in the blue rectangle. For this, we would probably need something in the direction of a ChildrenShape :). Also, the other challenge is to not let the RTNest make the decision of where to place the children.
What do you say?
Doru
On Sun, Apr 27, 2014 at 9:37 PM, Alexandre Bergel alexandre.bergel@me.com wrote: Hi!
I’ve worked a bit on the composition. So far, we have three ways to compose shapes:
1 - RTCompositeShape. This is the composition that is used with +
-=-=-=-=-=-=-=-=-=-= | v s1 s2 e | v := RTView new. s1 := RTBox new size: #yourself; color: Color blue. s2 := RTEllipse new size: [ :value | value / 2 ]; color: Color red. e := (RTCompositeShape with: s1 with: s2) elementOn: 50. v add: e. v -=-=-=-=-=-=-=-=-=-= <Screen Shot 2014-04-27 at 4.30.40 PM.png>
2 - RTHorizontalCompositeShape Here is the effect of replacing RTCompositeShape by RTHorizontalCompositeShape in the previous example <Screen Shot 2014-04-27 at 4.33.32 PM.png>
3 - RTVerticalCompositeShape <Screen Shot 2014-04-27 at 4.33.52 PM.png>
All the shapes composed with RTCompositeShape have the same size. This is useful for example if you do: (RTBox new + RTLabel) elementOn: ‘Hello World’. You typically want the label and the box have the same size. When you want to line up shapes, I guess you do not care of having all the shapes of the same size.
This new behavior for horizontal and vertical should address what you need Leo.
The nice thing, in my opinion, is that we should be able to have any kind of strategy, for example, a grid of shapes. This is really a matter of small programming.
Let me know if this is what you expect. Just update Roassal for this.
Cheers, Alexandre
On Apr 25, 2014, at 5:55 AM, Leo Perard leo.perard@gmail.com wrote:
On Thu, Apr 24, 2014 at 10:00 PM, Alexandre Bergel alexandre.bergel@me.com wrote: How can I reproduce this bug? What do you do exactly? With this example you can reproduce it easily :
view := RTView new. box := RTBox new color: Color green. label := RTLabel new. el := (RTCompositeShape new shape1: box; shape2: label). el := (RTHorizontalCompositeShape new shape1: el; shape2: (RTEllipse new color: Color red)) elementOn: 'Hello World'. view add: el.
view addMenu: 'Color' callback: [ el shape shape2 color: Color blue. el update. view signalUpdate ].
view open
And even if I don't have a composite shape composed with another composite shape, the update is not good.
Leo Perard _______________________________________________ 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
"Every thing has its own flow"
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- Leo Perard _______________________________________________ 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
-- Leo Perard _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
On Tue, Apr 29, 2014 at 2:35 AM, Alexandre Bergel alexandre.bergel@me.comwrote:
I have the impression you need to manually build your composed shape, with a dedicated builder (i.e., subclass of RTBuilder).
What are you trying to achieve?
Alexandre
I don't think I need a composed shape builder. I just want to play dynamicly with composite shapes.
I don't see the for which features the builder could be usefull ?
I was expecting this question :-) Two problems I see: - layout are made to work with elements, not shape. A shape does not have a position - RTNest is made to work with elements
I will think about it.
Alexandre
On Apr 27, 2014, at 4:59 PM, Tudor Girba tudor@tudorgirba.com wrote:
Hi Alex,
This starts to look good.
The next thing is to specify where nested children go :). For example, I would want to be able to specify that the nested children should be in the blue rectangle. For this, we would probably need something in the direction of a ChildrenShape :). Also, the other challenge is to not let the RTNest make the decision of where to place the children.
What do you say?
Doru
On Sun, Apr 27, 2014 at 9:37 PM, Alexandre Bergel alexandre.bergel@me.com wrote: Hi!
I’ve worked a bit on the composition. So far, we have three ways to compose shapes:
1 - RTCompositeShape. This is the composition that is used with +
-=-=-=-=-=-=-=-=-=-= | v s1 s2 e | v := RTView new. s1 := RTBox new size: #yourself; color: Color blue. s2 := RTEllipse new size: [ :value | value / 2 ]; color: Color red. e := (RTCompositeShape with: s1 with: s2) elementOn: 50. v add: e. v -=-=-=-=-=-=-=-=-=-= <Screen Shot 2014-04-27 at 4.30.40 PM.png>
2 - RTHorizontalCompositeShape Here is the effect of replacing RTCompositeShape by RTHorizontalCompositeShape in the previous example <Screen Shot 2014-04-27 at 4.33.32 PM.png>
3 - RTVerticalCompositeShape <Screen Shot 2014-04-27 at 4.33.52 PM.png>
All the shapes composed with RTCompositeShape have the same size. This is useful for example if you do: (RTBox new + RTLabel) elementOn: ‘Hello World’. You typically want the label and the box have the same size. When you want to line up shapes, I guess you do not care of having all the shapes of the same size.
This new behavior for horizontal and vertical should address what you need Leo.
The nice thing, in my opinion, is that we should be able to have any kind of strategy, for example, a grid of shapes. This is really a matter of small programming.
Let me know if this is what you expect. Just update Roassal for this.
Cheers, Alexandre
On Apr 25, 2014, at 5:55 AM, Leo Perard leo.perard@gmail.com wrote:
On Thu, Apr 24, 2014 at 10:00 PM, Alexandre Bergel alexandre.bergel@me.com wrote: How can I reproduce this bug? What do you do exactly? With this example you can reproduce it easily :
view := RTView new. box := RTBox new color: Color green. label := RTLabel new. el := (RTCompositeShape new shape1: box; shape2: label). el := (RTHorizontalCompositeShape new shape1: el; shape2: (RTEllipse new color: Color red)) elementOn: 'Hello World'. view add: el.
view addMenu: 'Color' callback: [ el shape shape2 color: Color blue. el update. view signalUpdate ].
view open
And even if I don't have a composite shape composed with another composite shape, the update is not good.
Leo Perard _______________________________________________ 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
"Every thing has its own flow" _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
I found 2 bugs when I tried to change color of one of the shape in the RTCompositeShape
*view := RTView new.* *el := (RTCompositeShape new*
* shape1: RTBox new;* * shape2: RTLabel new)* * elementOn: 'Element'. * *view add: el.* *view canvas addMenu: 'Color' callback: [ el shape shape1 color: Color red. el update. view canvas signalUpdate ].* *view open*
The color of the box is changed but it does not have the good size anymore.
The second one is with one of the shape is a RTCompositeShape itself
*view := RTView new.* *el := (RTHorizontalCompositeShape new* * shape1: (RTCompositeShape new shape1: RTBox new; shape2: RTLabel new);* * shape2: (RTEllipse new size: 10; color: Color blue))* * elementOn: 'Element'. * *view add: el.* *view canvas addMenu: 'Color' callback: [ el shape shape2 color: Color red. el update. view canvas signalUpdate ].* *view open*
Raise an error :
RTCompositeShape>>#updateFor:trachelShape: is missing
view := RTView new. el := (RTCompositeShape new shape1: RTBox new; shape2: RTLabel new) elementOn: 'Element'. view add: el. view canvas addMenu: 'Color' callback: [ el shape shape1 color: Color red. el update. view canvas signalUpdate ]. view open
The color of the box is changed but it does not have the good size anymore.
Roassal shapes have been designed to be factory of Trachel shapes. At the end, everything boils down into trachel shapes, which are agnostic to your model.
If you want to change the color, you should directly talk to the trachel shape, as with: =-=-=-==-=-=-==-=-=-==-=-=-= view := RTView new. el := (RTCompositeShape new shape1: RTBox new; shape2: RTLabel new) elementOn: 'Element'. view add: el. view canvas addMenu: 'Color' callback: [ el trachelShape shape1 color: Color red. view signalUpdate ]. view open =-=-=-==-=-=-==-=-=-==-=-=-=
The second one is with one of the shape is a RTCompositeShape itself
view := RTView new. el := (RTHorizontalCompositeShape new shape1: (RTCompositeShape new shape1: RTBox new; shape2: RTLabel new); shape2: (RTEllipse new size: 10; color: Color blue)) elementOn: 'Element'. view add: el. view canvas addMenu: 'Color' callback: [ el shape shape2 color: Color red. el update. view canvas signalUpdate ]. view open
Actually, this is a bug in Roassal2, and this is the same problem than in your previous example.
You can easily bypass this bug by directly talking to the trachel shape. -=-=-=-=-=-=-=-=-= view := RTView new. el := (RTHorizontalCompositeShape new shape1: (RTCompositeShape new shape1: RTBox new; shape2: RTLabel new); shape2: (RTEllipse new size: 10; color: Color blue)) elementOn: 'Element'. view add: el. view canvas addMenu: 'Color' callback: [ el trachelShape shape2 color: Color red. view signalUpdate ]. view open -=-=-=-=-=-=-=-=-=
Cheers, Alexandre
Raise an error :
<subclassResponsibility-RTCompositeShape.png>
RTCompositeShape>>#updateFor:trachelShape: is missing -- Cheers, Leo Perard University of Lille 1 _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
On Tue, Apr 29, 2014 at 2:24 AM, Alexandre Bergel alexandre.bergel@me.comwrote:
view := RTView new. el := (RTHorizontalCompositeShape new shape1: (RTCompositeShape new shape1: RTBox new; shape2: RTLabel new); shape2: (RTEllipse new size: 10; color: Color blue)) elementOn: 'Element'. view add: el. view canvas addMenu: 'Color' callback: [ el trachelShape shape2 color: Color red. view signalUpdate ]. view open
Ok cool I will do it like that
Well, you can always stack up elements. Consider this example and its cool animation:
-=-=-=—=-=-=-=—=-=-=-=—=-=-=-=—= | v shape elements | v := RTView new. shape := RTEllipse new color: (Color purple alpha: 0.1); size: #yourself. elements := shape elementsOn: (1 to: 100 by: 10). v addAll: elements.
v canvas addMenu: 'Right!' callback: [ elements do: [ :e | RTLinearMove new to: e model @ 0 during: 1 on: e in: v ] ].
v canvas addMenu: 'Left!' callback: [ elements do: [ :e | RTLinearMove new to: e model negated @ 0 during: 1 on: e in: v ] ].
v canvas addMenu: 'Up!' callback: [ elements do: [ :e | RTLinearMove new to: 0 @ e model negated during: 1 on: e in: v ] ].
v canvas addMenu: 'Down!' callback: [ elements do: [ :e | RTLinearMove new to: 0 @ e model during: 1 on: e in: v ] ].
v -=-=-=—=-=-=-=—=-=-=-=—=-=-=-=—=
The problem that remains open is how to have other shapes than a simple circle, label, box, or svg path for an element.
Cheers, Alexandre
On Apr 28, 2014, at 9:21 AM, Ben Coman btc@openInWorld.com wrote:
At first glance that seems a little restrictive. I immediately think of trying to make a bulleye target as a composite of concentric circles of different sizes. Though I can't think of any other examples off hand. cheers -ben
Hop few points and questions.
If I don't want one that one of the scales its size on the element size on can I do that ? And I think there is some bug in the layout of composite shape composed with others composite shape.
On the screenshot I would like : - the red ellipse do not scale and keep the size I initialized - the layout don't do creepy things ^^
On Thu, Apr 24, 2014 at 4:49 PM, Leo Perard leo.perard@gmail.com wrote:
As I use a lot of CompositeShape in my project I will give you a lot of feedbacks ;-) I like the composition of composite shape itself. I needed it now it will so much easier.
But is it possible the put a RTCompositeShape as fixed ? Let me give you an example to show you I'm working on a Menu in my vizualisation so i want them fix. But a menu is a label and its "background' so a composite shape. Can I set it as fixed ?
On Thu, Apr 24, 2014 at 3:39 PM, Alexandre Bergel < alexandre.bergel@me.com> wrote:
Hi!
I’ve just introduced a new class TRExtensibleLabelShape and TRLabelShape. This will ease the problem we are experiencing with using labels in a composed shape.
I would like now to discuss about how to compose shapes. This has been a big discussion for at least 5 years. I propose a solution in this email, I hope this will make most of us happy :-)
Consider the example:
-=-=-=-=-=-=-=-= | v s1 s2 c es | v := RTView new.
s1 := (RTEllipse new size: #yourself; color: (Color blue alpha: 0.4)). s2 := (RTLabel new text: 'Hello World'; height: 10).
c := RTCompositeShape new shape1: s1; shape2: s2; offset2: 0 @ -30.
es := c elementsOn: #(30 60 80). es @ RTDraggable. v addAll: es.
es when: TRMouseClick do: [ :evt | evt element remove. v signalUpdate ].
RTHorizontalLineLayout on: v elements. v open -=-=-=-=-=-=-=-=
This is the output:
If you click on an element, then the element with its label is properly removed. Yupi! Leo will be happy with that :-) The reason is that how can I specify to have s2 above s1? What should I put in offset2 ? Instead of fiddling with blocks like [:shape1 :shape2 :element | … ] I have introduced RTHorizontalCompositeShape and RTVerticalCompositeShape just to try whether it make sense or not.
We can have
| v s1 s2 c es | v := RTView new.
s1 := (RTEllipse new size: #yourself; color: (Color blue alpha: 0.4)). s2 := (RTLabel new text: 'Hello World'; height: 10).
c := RTHorizontalCompositeShape new shape1: s1; shape2: s2.
es := c elementsOn: #(30 60 80). es @ RTDraggable. v addAll: es.
RTHorizontalLineLayout on: v elements. v -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Replacing Horizontal by Vertical works as expected.
You can also compose these things. Look at that:
| v s1 s2 c es | v := RTView new.
s1 := (RTEllipse new size: #yourself; color: (Color blue alpha: 0.4)). s2 := (RTLabel new text: 'Hello World'; height: 10).
c2 := RTVerticalCompositeShape new shape1: s1; shape2: s2. c := RTHorizontalCompositeShape new shape1: s1; shape2: c2.
es := c elementsOn: #(30 60 80). es @ RTDraggable. v addAll: es.
RTHorizontalLineLayout on: v elements. v -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Are we happy with RTVerticalCompositeShape, RTHorizontalCompositeShape and RTCompositeShape ?
If yes, then RTLabelling (and its problem of passing the view along :-) will be obsolete.
Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- Leo Perard
If I don't want one that one of the scales its size on the element size on can I do that ?
What do you want exactly? That the red dot has always the same size?
Alexandre
On Thu, Apr 24, 2014 at 10:01 PM, Alexandre Bergel alexandre.bergel@me.comwrote:
If I don't want one that one of the scales its size on the element size
on can I do that ?
What do you want exactly? That the red dot has always the same size?
Exactly
Alexandre
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: 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 -
kilon alios -
Leo Perard -
Tudor Girba