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(a)me.com>wrote;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(a)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(a)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(a)gmail.com> wrote:
> On Thu, Apr 24, 2014 at 10:00 PM, Alexandre Bergel <
alexandre.bergel(a)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(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel
http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
www.tudorgirba.com
"Every thing has its own flow"
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel
http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev