11:37 a.m.
Hi,
I'm not sure it is but I think I have found a bug where elements share the
same instance of a shape.
Here an example:
view := RTView new.
els := (RTBox new size: 20) elementsOn: (1 to: 10).
view addAll: els.
els do: [ :e |
e on: TRMouseClick do: [ :event |
e shape color: Color random. e update. els atRandom update. view
signalUpdate ]
].
RTHorizontalLineLayout on: els.
view open
It should only change the color of one element but it doesn't.
So I don't know if it is wanted or not.
--
Cheers,
Leo Perard
University of Lille 1
11:44 a.m.
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:
Hi,
I'm not sure it is but I think I have found a bug where elements share the same
instance of a shape.
Here an example:
view := RTView new.
els := (RTBox new size: 20) elementsOn: (1 to: 10).
view addAll: els.
els do: [ :e |
e on: TRMouseClick do: [ :event |
e shape color: Color random. e update. els atRandom update. view signalUpdate ]
].
RTHorizontalLineLayout on: els.
view open
It should only change the color of one element but it doesn't.
So I don't know if it is wanted or not.
--
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
1:02 p.m.
Yeah exactly bug or feature :)
In some case you could want this feature but I'm not sure this is the
original behavior we want.
On Wed, Jun 25, 2014 at 11:44 AM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com>
wrote:
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:
> Hi,
>
> I'm not sure it is but I think I have found a bug where elements share
the same instance of a shape.
>
> Here an example:
>
> view := RTView new.
>
> els := (RTBox new size: 20) elementsOn: (1 to: 10).
> view addAll: els.
>
> els do: [ :e |
> e on: TRMouseClick do: [ :event |
> e shape color: Color random. e update. els atRandom
update. view signalUpdate ]
> ].
>
> RTHorizontalLineLayout on: els.
> view open
>
> It should only change the color of one element but it doesn't.
> So I don't know if it is wanted or not.
> --
> 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
_______________________________________________
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
10:26 p.m.
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:
e on: TRMouseClick do: [ :event |
e shape color: Color random. e update. els atRandom 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:
Hi,
I'm not sure it is but I think I have found a bug where elements share the same
instance of a shape.
Here an example:
view := RTView new.
els := (RTBox new size: 20) elementsOn: (1 to: 10).
view addAll: els.
els do: [ :e |
e on: TRMouseClick do: [ :event |
e shape color: Color random. e update. els atRandom update. view signalUpdate ]
].
RTHorizontalLineLayout on: els.
view open
It should only change the color of one element but it doesn't.
So I don't know if it is wanted or not.
--
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
12:06 a.m.
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:
> e on: TRMouseClick do: [ :event |
> e shape color: Color random. e update. els atRandom
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:
> Hi,
>
> I'm not sure it is but I think I have found a bug where elements share
the same instance of a shape.
>
> Here an example:
>
> view := RTView new.
>
> els := (RTBox new size: 20) elementsOn: (1 to: 10).
> view addAll: els.
>
> els do: [ :e |
> e on: TRMouseClick do: [ :event |
> e shape color: Color random. e update. els atRandom
update. view signalUpdate ]
> ].
>
> RTHorizontalLineLayout on: els.
> view open
>
> It should only change the color of one element but it doesn't.
> So I don't know if it is wanted or not.
> --
> 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
_______________________________________________
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
10:22 a.m.
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>:
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:
>
> > e on: TRMouseClick do: [ :event |
> > e shape color: Color random. e update. els atRandom
> 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:
>
> > Hi,
> >
> > I'm not sure it is but I think I have found a bug where elements share
> the same instance of a shape.
> >
> > Here an example:
> >
> > view := RTView new.
> >
> > els := (RTBox new size: 20) elementsOn: (1 to: 10).
> > view addAll: els.
> >
> > els do: [ :e |
> > e on: TRMouseClick do: [ :event |
> > e shape color: Color random. e update. els atRandom
> update. view signalUpdate ]
> > ].
> >
> > RTHorizontalLineLayout on: els.
> > view open
> >
> > It should only change the color of one element but it doesn't.
> > So I don't know if it is wanted or not.
> > --
> > 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
>
>
> _______________________________________________
> 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*
10:30 a.m.
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.
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.
Uko
On 03 Jul 2014, at 10:22, Guillaume Larcheveque <guillaume.larcheveque(a)gmail.com>
wrote:
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>:
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:
> e on: TRMouseClick do: [ :event |
> e shape color: Color random. e update. els atRandom 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:
> Hi,
>
> I'm not sure it is but I think I have found a bug where elements share the same
instance of a shape.
>
> Here an example:
>
> view := RTView new.
>
> els := (RTBox new size: 20) elementsOn: (1 to: 10).
> view addAll: els.
>
> els do: [ :e |
> e on: TRMouseClick do: [ :event |
> e shape color: Color random. e update. els atRandom update. view
signalUpdate ]
> ].
>
> RTHorizontalLineLayout on: els.
> view open
>
> It should only change the color of one element but it doesn't.
> So I don't know if it is wanted or not.
> --
> 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
_______________________________________________
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
10:53 a.m.
2014-07-03 10:30 GMT+02:00 Yuriy Tymchuk <yuriy.tymchuk(a)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.
Uko
On 03 Jul 2014, at 10:22, Guillaume Larcheveque <
guillaume.larcheveque(a)gmail.com> wrote:
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>:
> 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:
>>
>> > e on: TRMouseClick do: [ :event |
>> > e shape color: Color random. e update. els atRandom
>> 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:
>>
>> > Hi,
>> >
>> > I'm not sure it is but I think I have found a bug where elements share
>> the same instance of a shape.
>> >
>> > Here an example:
>> >
>> > view := RTView new.
>> >
>> > els := (RTBox new size: 20) elementsOn: (1 to: 10).
>> > view addAll: els.
>> >
>> > els do: [ :e |
>> > e on: TRMouseClick do: [ :event |
>> > e shape color: Color random. e update. els atRandom
>> update. view signalUpdate ]
>> > ].
>> >
>> > RTHorizontalLineLayout on: els.
>> > view open
>> >
>> > It should only change the color of one element but it doesn't.
>> > So I don't know if it is wanted or not.
>> > --
>> > 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
>>
>>
>> _______________________________________________
>> 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
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
*Guillaume Larcheveque*
11:09 a.m.
Le 03/07/2014 10:53, Guillaume Larcheveque a écrit :
2014-07-03 10:30 GMT+02:00 Yuriy Tymchuk <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.
Read:
Lightweight Design Pattern :) A perfectly understandable design decision
from Roassal in the context of graphics... just don't forget the side
effects.
Now a copy on write design for shapes could be nice (create a derived
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).
Alexandre, I think this is your call :)
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.
+1. See above, but remember that even the copy on write design does the
creation lazily (only when highlighting, not when deciding to allow
possible highlighting).
Thierry
--
Thierry Goubier
CEA list
Laboratoire des Fondations des Systèmes Temps Réel Embarqués
91191 Gif sur Yvette Cedex
France
Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95
9:07 p.m.
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 <thierry.goubier(a)cea.fr> wrote:
Le 03/07/2014 10:53, Guillaume Larcheveque a écrit :
>
>
>
> 2014-07-03 10:30 GMT+02:00 Yuriy Tymchuk <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.
Read:
Lightweight Design Pattern :) A perfectly understandable design decision from Roassal in
the context of graphics... just don't forget the side effects.
Now a copy on write design for shapes could be nice (create a derived 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).
Alexandre, I think this is your call :)
>
>
> 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.
+1. See above, but remember that even the copy on write design does the creation lazily
(only when highlighting, not when deciding to allow possible highlighting).
Thierry
--
Thierry Goubier
CEA list
Laboratoire des Fondations des Systèmes Temps Réel Embarqués
91191 Gif sur Yvette Cedex
France
Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
9:12 p.m.
No not for me at least. I don't want to see the code of the visualization.
But I was wondering, if I have to modify the trachelShape and not the
rossal shape, why the update refresh the roassal shape ? It should not
update the trachelShape instead of the roassal one ?
On Thu, Jul 3, 2014 at 9:07 PM, Alexandre Bergel <alexandre.bergel(a)me.com>
wrote:
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 <thierry.goubier(a)cea.fr>
wrote:
>
>
> Le 03/07/2014 10:53, Guillaume Larcheveque a écrit :
>>
>>
>>
>> 2014-07-03 10:30 GMT+02:00 Yuriy Tymchuk <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.
>
> Read:
>
> Lightweight Design Pattern :) A perfectly understandable design decision
from Roassal in the context of graphics... just don't forget the side
effects.
>
> Now a copy on write design for shapes could be nice (create a derived
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).
>
> Alexandre, I think this is your call :)
>
>>
>>
>> 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.
>
> +1. See above, but remember that even the copy on write design does the
creation lazily (only when highlighting, not when deciding to allow
possible highlighting).
>
> Thierry
> --
> Thierry Goubier
> CEA list
> Laboratoire des Fondations des Systèmes Temps Réel Embarqués
> 91191 Gif sur Yvette Cedex
> France
> Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95
> _______________________________________________
> 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
--
Cheers,
Leo Perard
University of Lille 1
9:37 p.m.
RTElement>>update update the Trachel shape by recomputing it using the Roassal
shape.
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
On Jul 3, 2014, at 3:12 PM, Leo Perard <leo.perard(a)gmail.com> wrote:
No not for me at least. I don't want to see the code of the
visualization.
But I was wondering, if I have to modify the trachelShape and not the rossal shape, why
the update refresh the roassal shape ? It should not update the trachelShape instead of
the roassal one ?
On Thu, Jul 3, 2014 at 9:07 PM, Alexandre Bergel <alexandre.bergel(a)me.com> wrote:
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 <thierry.goubier(a)cea.fr> wrote:
>
>
> Le 03/07/2014 10:53, Guillaume Larcheveque a écrit :
>>
>>
>>
>> 2014-07-03 10:30 GMT+02:00 Yuriy Tymchuk <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.
>
> Read:
>
> Lightweight Design Pattern :) A perfectly understandable design decision from
Roassal in the context of graphics... just don't forget the side effects.
>
> Now a copy on write design for shapes could be nice (create a derived 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).
>
> Alexandre, I think this is your call :)
>
>>
>>
>> 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.
>
> +1. See above, but remember that even the copy on write design does the creation
lazily (only when highlighting, not when deciding to allow possible highlighting).
>
> Thierry
> --
> Thierry Goubier
> CEA list
> Laboratoire des Fondations des Systèmes Temps Réel Embarqués
> 91191 Gif sur Yvette Cedex
> France
> Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95
> _______________________________________________
> 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
--
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
9:01 p.m.
I see the point. Hard to find a good balance. As you said, maybe the best is to remove
access to the roassal shape from an element.
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
On Jul 3, 2014, at 4:53 AM, Guillaume Larcheveque <guillaume.larcheveque(a)gmail.com>
wrote:
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.
9 p.m.
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.
I have the same feeling that you. It is a kind of reflexion mechanism (a bit like the
#class message you can send to any object). This should not be used normally.
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”.
Yes, there is the method:
RTElement(RTShapeObject)>>color: aColor
^ trachelShape color: aColor
However it can be disturbing because what Leo wrote seems correct.
What is the reason to keep the RTShape in each RTElement?
It may append that you want to “refresh” the element, from its shape. I have seen couple
of case like that.
Alexandre
2014-07-03 0:06 GMT+02:00 Leo Perard <leo.perard(a)gmail.com>:
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:
> e on: TRMouseClick do: [ :event |
> e shape color: Color random. e update. els atRandom 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:
> Hi,
>
> I'm not sure it is but I think I have found a bug where elements share the same
instance of a shape.
>
> Here an example:
>
> view := RTView new.
>
> els := (RTBox new size: 20) elementsOn: (1 to: 10).
> view addAll: els.
>
> els do: [ :e |
> e on: TRMouseClick do: [ :event |
> e shape color: Color random. e update. els atRandom update. view
signalUpdate ]
> ].
>
> RTHorizontalLineLayout on: els.
> view open
>
> It should only change the color of one element but it doesn't.
> So I don't know if it is wanted or not.
> --
> 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
_______________________________________________
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
8:58 p.m.
Hi Leo,
Yes, a Roassal is shared by all the elements. For the same reason that a “class” is the
same for all the instances of that class.
If you want to change some visual attribute to an element, you should do it via its
trachelShape. At the end, everything boil down into Trachel, which is a thin layer on top
of Athens.
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
On Jul 2, 2014, at 6:06 PM, Leo Perard <leo.perard(a)gmail.com> wrote:
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:
> e on: TRMouseClick do: [ :event |
> e shape color: Color random. e update. els atRandom 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:
> Hi,
>
> I'm not sure it is but I think I have found a bug where elements share the same
instance of a shape.
>
> Here an example:
>
> view := RTView new.
>
> els := (RTBox new size: 20) elementsOn: (1 to: 10).
> view addAll: els.
>
> els do: [ :e |
> e on: TRMouseClick do: [ :event |
> e shape color: Color random. e update. els atRandom update. view
signalUpdate ]
> ].
>
> RTHorizontalLineLayout on: els.
> view open
>
> It should only change the color of one element but it doesn't.
> So I don't know if it is wanted or not.
> --
> 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
_______________________________________________
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
3370
days inactive
3378
days old
14 comments
5 participants
participants (5)
-
Alexandre Bergel -
Goubier Thierry -
Guillaume Larcheveque -
Leo Perard -
Yuriy Tymchuk