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 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