This is interesting indeed. I think that shape singularity was made for optimisation. On the other hand you can define color as a block, so you will get different color for the same shape. Now the question: is this a bug or a feature :) Uko On 25 Jun 2014, at 11:37, Leo Perard <leo.perard(a)gmail.com> wrote: the same instance of a shape. update. view signalUpdate ] _______________________________________________ Moose-dev mailing list Moose-dev(a)iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

Hi Leo, Sorry to reply so late. Your script does exactly what it is supposed to do. Maybe part of the shape semantic is not clear. Consider this part of the script: update. view signalUpdate ] You click on an element e, which means you change the shape of the element. You update the element itself, it therefore changes its color. But with "els atRandom update” you also update another element. Since the shape is shared by all the elements, the behavior is indeed correct. A shape is shared with all the objects. What is not shared are Trachel shapes. You have the following relations: shape := RTBox new size: 10. e1 := shape elementOn: 'hello'. e2 := shape elementOn: 'world'. self assert: e1 shape == e2 shape. self assert: e1 shape ~~ e1 trachelShape. self assert: (e1 shape isKindOf: RTBox). self assert: (e1 trachelShape isKindOf: TRBoxShape). self assert: e1 trachelShape ~~ e2 trachelShape. Let me know if something is not clear. I have written this in the class comment of RTShape. Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. On Jun 25, 2014, at 5:37 AM, Leo Perard <leo.perard(a)gmail.com> wrote: the same instance of a shape. update. view signalUpdate ] _______________________________________________ Moose-dev mailing list Moose-dev(a)iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

In my opinion, this shape is not really a shape but more a kind of shapeBuilder and it's strange that an element still know such kind of builder. The roassal api is good on that point because to change the color of an element you should call "e color: aColor" and not "e shape color: aColor". However it can be disturbing because what Leo wrote seems correct. What is the reason to keep the RTShape in each RTElement? 2014-07-03 0:06 GMT+02:00 Leo Perard <leo.perard(a)gmail.com>om>: I understand that a shape is shared by elements but what I do not is why ? For example shape := RTBox new color: Color red. els := shape elementsOn: (1 to: 10). els do: [ :e | e on: TRMouseLeftClick do: [ :event | e shape color: Color random. e update. view signalUpdate ]. e on: TRMouseRightClick do: [ :event | e shape borderColor: Color random. e update. view signalUpdate ] ] In this example if I change an element with a left click its color will change so it is ok. But after, I change the border color wiht a right click, the border will be change AND the color too. But I did not want that, just the border. Do you see my point ? I do not understant why shape should be shared ? On Wed, Jul 2, 2014 at 10:26 PM, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: Hi Leo, Sorry to reply so late. Your script does exactly what it is supposed to do. Maybe part of the shape semantic is not clear. Consider this part of the script: You click on an element e, which means you change the shape of the element. You update the element itself, it therefore changes its color. But with "els atRandom update” you also update another element. Since the shape is shared by all the elements, the behavior is indeed correct. A shape is shared with all the objects. What is not shared are Trachel shapes. You have the following relations: shape := RTBox new size: 10. e1 := shape elementOn: 'hello'. e2 := shape elementOn: 'world'. self assert: e1 shape == e2 shape. self assert: e1 shape ~~ e1 trachelShape. self assert: (e1 shape isKindOf: RTBox). self assert: (e1 trachelShape isKindOf: TRBoxShape). self assert: e1 trachelShape ~~ e2 trachelShape. Let me know if something is not clear. I have written this in the class comment of RTShape. Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. On Jun 25, 2014, at 5:37 AM, Leo Perard <leo.perard(a)gmail.com> wrote: _______________________________________________ Moose-dev mailing list Moose-dev(a)iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- Cheers, Leo Perard University of Lille 1 _______________________________________________ Moose-dev mailing list Moose-dev(a)iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- Guillaume Larcheveque _______________________________________________ Moose-dev mailing list Moose-dev(a)iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

2014-07-03 10:30 GMT+02:00 Yuriy Tymchuk &lt;yuriy.tymchuk(a)me.com <mailto:yuriy.tymchuk@me.com>>: For me it’s completely fine. Shape is a shape, and then elements can use to show themselves.Now if you have a sale and change it’s color then all the elements show this shape with different color. If you need things with different colors, you need different shapes. It creates a kind of implicit group that is not really easy to understand and to maintain. If you want to change the color or any other property of a shape on lots of elements, a better way would be to use a group and then ask to this group to change and update all its elements. It's terribly confusing to change a single element and to have a modification on every elements that were created in the same way. In addition those elements will not be updated soon so you will not see that they changed until you update them.

Other thing is that it would be nice to have some highlight option, so you don’t need to create 1000 shapes only if you can to be able to highlight individual element.

Hard to make decisions that are both intuitive and easy to use. Maybe an element should not know about its roassal shape. But being able to “reset” the visual aspects of an element is interesting. Especially if its model has changed. For example: -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= | v | v := RTView new. v @ RTDraggableView. shape := RTBox new width: [ :c | c numberOfVariables max: 5 ]; height: [ :c | c numberOfMethods max: 5 ]. elements := shape elementsOn: RTObject withAllSubclasses. v addAll: elements. RTFlowLayout on: elements. elements @ RTPopup. v canvas addMenu: 'Refresh' callback: [ v elements do: #update ]. v -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= You can leave this visualization open, and modifying your code. Pressing the ‘Refresh’ button will update the size of all your classes. Does this example convince you? Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. On Jul 3, 2014, at 5:09 AM, Goubier Thierry &lt;thierry.goubier(a)cea.fr&gt; wrote: from Roassal in the context of graphics... just don't forget the side effects. shape object once you start changing some attributes of an element), as well as a context design (arrange so that some attributes changes such as highlighting are a property of the element and do not require creation of the shape). creation lazily (only when highlighting, not when deciding to allow possible highlighting). _______________________________________________ Moose-dev mailing list Moose-dev(a)iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

It creates a kind of implicit group that is not really easy to understand and to maintain. If you want to change the color or any other property of a shape on lots of elements, a better way would be to use a group and then ask to this group to change and update all its elements. It's terribly confusing to change a single element and to have a modification on every elements that were created in the same way. In addition those elements will not be updated soon so you will not see that they changed until you update them.

I understand that a shape is shared by elements but what I do not is why ? For example shape := RTBox new color: Color red. els := shape elementsOn: (1 to: 10). els do: [ :e | e on: TRMouseLeftClick do: [ :event | e shape color: Color random. e update. view signalUpdate ]. e on: TRMouseRightClick do: [ :event | e shape borderColor: Color random. e update. view signalUpdate ] ] In this example if I change an element with a left click its color will change so it is ok. But after, I change the border color wiht a right click, the border will be change AND the color too. But I did not want that, just the border. Do you see my point ? I do not understant why shape should be shared ? On Wed, Jul 2, 2014 at 10:26 PM, Alexandre Bergel &lt;alexandre.bergel(a)me.com&gt; wrote: Hi Leo, Sorry to reply so late. Your script does exactly what it is supposed to do. Maybe part of the shape semantic is not clear. Consider this part of the script: You click on an element e, which means you change the shape of the element. You update the element itself, it therefore changes its color. But with "els atRandom update” you also update another element. Since the shape is shared by all the elements, the behavior is indeed correct. A shape is shared with all the objects. What is not shared are Trachel shapes. You have the following relations: shape := RTBox new size: 10. e1 := shape elementOn: 'hello'. e2 := shape elementOn: 'world'. self assert: e1 shape == e2 shape. self assert: e1 shape ~~ e1 trachelShape. self assert: (e1 shape isKindOf: RTBox). self assert: (e1 trachelShape isKindOf: TRBoxShape). self assert: e1 trachelShape ~~ e2 trachelShape. Let me know if something is not clear. I have written this in the class comment of RTShape. Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. On Jun 25, 2014, at 5:37 AM, Leo Perard &lt;leo.perard(a)gmail.com&gt; wrote: _______________________________________________ Moose-dev mailing list Moose-dev(a)iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- Cheers, Leo Perard University of Lille 1 _______________________________________________ Moose-dev mailing list Moose-dev(a)iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev