Brainstorming : composition of shapes
Locked
12
12
 
|
Well, you can always stack up elements. Consider this example and its cool animation:
-=-=-=—=-=-=-=—=-=-=-=—=-=-=-=—= | v shape elements | v := RTView new. shape := RTEllipse new color: (Color purple alpha: 0.1); size: #yourself. elements := shape elementsOn: (1 to: 100 by: 10). v addAll: elements. v canvas addMenu: 'Right!' callback: [ elements do: [ :e | RTLinearMove new to: e model @ 0 during: 1 on: e in: v ] ]. v canvas addMenu: 'Left!' callback: [ elements do: [ :e | RTLinearMove new to: e model negated @ 0 during: 1 on: e in: v ] ]. v canvas addMenu: 'Up!' callback: [ elements do: [ :e | RTLinearMove new to: 0 @ e model negated during: 1 on: e in: v ] ]. v canvas addMenu: 'Down!' callback: [ elements do: [ :e | RTLinearMove new to: 0 @ e model during: 1 on: e in: v ] ]. v -=-=-=—=-=-=-=—=-=-=-=—=-=-=-=—= The problem that remains open is how to have other shapes than a simple circle, label, box, or svg path for an element. Cheers, Alexandre On Apr 28, 2014, at 9:21 AM, Ben Coman <[hidden email]> wrote: > At first glance that seems a little restrictive. I immediately think of trying to make a bulleye target as a composite of concentric circles of different sizes. Though I can't think of any other examples off hand. > cheers -ben -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
In reply to this post by Leo Perard
> view := RTView new.
> el := (RTCompositeShape new > shape1: RTBox new; > shape2: RTLabel new) > elementOn: 'Element'. > view add: el. > view canvas addMenu: 'Color' callback: [ el shape shape1 color: Color red. el update. view canvas signalUpdate ]. > view open > > The color of the box is changed but it does not have the good size anymore. Roassal shapes have been designed to be factory of Trachel shapes. At the end, everything boils down into trachel shapes, which are agnostic to your model. If you want to change the color, you should directly talk to the trachel shape, as with: =-=-=-==-=-=-==-=-=-==-=-=-= view := RTView new. el := (RTCompositeShape new shape1: RTBox new; shape2: RTLabel new) elementOn: 'Element'. view add: el. view canvas addMenu: 'Color' callback: [ el trachelShape shape1 color: Color red. view signalUpdate ]. view open =-=-=-==-=-=-==-=-=-==-=-=-= > The second one is with one of the shape is a RTCompositeShape itself > > view := RTView new. > el := (RTHorizontalCompositeShape new > shape1: (RTCompositeShape new shape1: RTBox new; shape2: RTLabel new); > shape2: (RTEllipse new size: 10; color: Color blue)) > elementOn: 'Element'. > view add: el. > view canvas addMenu: 'Color' callback: [ el shape shape2 color: Color red. el update. view canvas signalUpdate ]. > view open Actually, this is a bug in Roassal2, and this is the same problem than in your previous example. You can easily bypass this bug by directly talking to the trachel shape. -=-=-=-=-=-=-=-=-= view := RTView new. el := (RTHorizontalCompositeShape new shape1: (RTCompositeShape new shape1: RTBox new; shape2: RTLabel new); shape2: (RTEllipse new size: 10; color: Color blue)) elementOn: 'Element'. view add: el. view canvas addMenu: 'Color' callback: [ el trachelShape shape2 color: Color red. view signalUpdate ]. view open -=-=-=-=-=-=-=-=-= Cheers, Alexandre > > Raise an error : > > <subclassResponsibility-RTCompositeShape.png> > > RTCompositeShape>>#updateFor:trachelShape: is missing > > -- > Cheers, > Leo Perard > University of Lille 1 > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
In reply to this post by Leo Perard
I have the impression you need to manually build your composed shape, with a dedicated builder (i.e., subclass of RTBuilder).
What are you trying to achieve? Alexandre On Apr 28, 2014, at 8:08 AM, Leo Perard <[hidden email]> wrote: > Sure. > > view := RTView new. > > container := (RTHorizontalCompositeShape new > shape1: RTBox new; > shape2: RTLabel new) > elementOn: 'Container'. > els := (RTBox new size: 9; color: Color red) elementsOn: (1 to: 16). > container @ RTDraggable. > > RTNest new layout: RTGridLayout; on: container nest: els. > view add: container; addAll: els. > view open > > I tried to "cheat" with the order of the calls. I nested the els just with the box and then I created a composite shape with + but no success. > > view := RTView new. > > container := RTBox new elementOn: 'Container'. > els := (RTBox new size: 9; color: Color red) elementsOn: (1 to: 16). > RTNest new layout: RTGridLayout; on: container nest: els. > container + RTLabel. > container @ RTDraggable. > > view add: container; addAll: els. > view open > > > On Mon, Apr 28, 2014 at 12:09 PM, Alexandre Bergel <[hidden email]> wrote: > Leo, can you provide an example of what was not working? > > Alexandre > > Le 28-04-2014 à 5:26, Leo Perard <[hidden email]> a écrit : > >> Great excatly the kind of thing I expected. >> >> I'm agree with Tudor, the nested element on a CompositeElement are really not great now. I maked some tests last weeks but no one was working. >> >> >> On Sun, Apr 27, 2014 at 9:59 PM, Tudor Girba <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote: >> >>> On Thu, Apr 24, 2014 at 10:00 PM, Alexandre Bergel <[hidden email]> 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 >>> [hidden email] >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> _______________________________________________ >> Moose-dev mailing list >> [hidden email] >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> >> >> >> -- >> www.tudorgirba.com >> >> "Every thing has its own flow" >> >> _______________________________________________ >> Moose-dev mailing list >> [hidden email] >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> >> >> >> -- >> Leo Perard >> _______________________________________________ >> Moose-dev mailing list >> [hidden email] >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > > > > -- > Leo Perard > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
Re: Brainstorming : composition of shapes
|
|
In reply to this post by abergel
On Tue, Apr 29, 2014 at 2:24 AM, Alexandre Bergel <[hidden email]> wrote:
Ok cool I will do it like that Cheers, Leo PerardUniversity of Lille 1 _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
Re: Brainstorming : composition of shapes
|
|
In reply to this post by abergel
On Tue, Apr 29, 2014 at 2:35 AM, Alexandre Bergel <[hidden email]> wrote: -- I have the impression you need to manually build your composed shape, with a dedicated builder (i.e., subclass of RTBuilder). I don't think I need a composed shape builder. I just want to play dynamicly with composite shapes. I don't see the for which features the builder could be usefull ? Cheers, Leo PerardUniversity of Lille 1 _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
Re: Brainstorming : composition of shapes
|
In reply to this post by abergel
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 <[hidden email]> wrote: Hi Kilon, _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote: > > > >> On Thu, Apr 24, 2014 at 10:00 PM, Alexandre Bergel <[hidden email]> 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 > >> [hidden email] > >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > > > -- > > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > > Alexandre Bergel http://www.bergel.eu > > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > > > > _______________________________________________ > > Moose-dev mailing list > > [hidden email] > > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > > > > > > > > > -- > > www.tudorgirba.com > > > > "Every thing has its own flow" > > > > _______________________________________________ > > Moose-dev mailing list > > [hidden email] > > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > > > > > _______________________________________________ > > Moose-dev mailing list > > [hidden email] > > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
Re: Brainstorming : composition of shapes
|
|
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 <[hidden email]> wrote:
_______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
> Is this going to carry to Mondrian as well ?
I do not understand this question :-) Roassal has a Mondrian builder in it, the class RTMondrianViewBuilder… Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
Re: Brainstorming : composition of shapes
|
|
I mean whether this way of composition of shapes will be also available to Mondrian. The way I understand it so far, is that Mondrian is a higher level library based on Roassal. It can do things that Roassal can in fewer steps focusing on visualization of object structures. So as Roassal needs to deal with complex shapes so does Mondrian. Am I correct ?
Do you mean that RTMondrianViewBuilder already acts as the compositor of complex shapes for Mondrian ? If yes that means that Mondrian will not be affected by these improvements ? On Tue, Apr 29, 2014 at 1:07 PM, Alexandre Bergel <[hidden email]> wrote:
_______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
> I mean whether this way of composition of shapes will be also available to Mondrian.
Could be. We have to see. Mondrian is (really) good only for a restricted set of situations. > The way I understand it so far, is that Mondrian is a higher level library based on Roassal. It can do things that Roassal can in fewer steps focusing on visualization of object structures. So as Roassal needs to deal with complex shapes so does Mondrian. Am I correct ? Yes, making Roassal things available in Mondrian is not a big deal. > Do you mean that RTMondrianViewBuilder already acts as the compositor of complex shapes for Mondrian ? If yes that means that Mondrian will not be affected by these improvements ? The class RTMondrianViewBuilder is simply a builder (i.e., generate low Roassal instruction from a specification tied to a particular model). It does not compose shapes, but instead generates elements with shapes (as all the builder do). Alexandre > > > On Tue, Apr 29, 2014 at 1:07 PM, Alexandre Bergel <[hidden email]> wrote: > > Is this going to carry to Mondrian as well ? > > I do not understand this question :-) > Roassal has a Mondrian builder in it, the class RTMondrianViewBuilder… > > Alexandre > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
«
Return to Moose
|
1 view|%1 views
| Free forum by Nabble | Edit this page |