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
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.