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.com> wrote:
> 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

--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.




_______________________________________________
Moose-dev mailing list
Moose-dev@iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev