29 Apr
2014
29 Apr
'14
11:49 a.m.
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(a)me.com> wrote:
Hi Kilon,
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
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:
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
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
_______________________________________________
Moose-dev mailing list
Moose-dev(a)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(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