[squeak-dev] Squeak clock face
Lou at Keystone-Software.com
Tue Dec 19 16:41:07 UTC 2017
The y-value as you call it is different but I have played with different values and it doesn't
change anything. Anyway, now that I understand (or at least I think I do) what position in the
pointerMorph and the TransformationMorph do, I don't think that would be the problem. To
recap: the position in the pointerMorph sets the point along the length of the pointer that
the pointer will rotate around. The position in the TransformationMorph is the point in its
parent that the rotation takes place.
This is the #dialCenter or center of the main morph or clock. I suspect this may be some kind
of funny timing problem. I also suspect it may have something to do with the whole rotation
problem, which I think may have something to do with the positions being changed from the
position within the parent to the position on the screen.
It seems odd to me that when the position of a new TransformationMorph is set it is based on
where it is to go in its parent morph but if you ask it its position later, it answers its
position on the screen. I say that this disconnection may have something to do with the
rotation problem because I think the rotation code does some math based upon the position of
the morph. I expect the code thinks it is using a position based upon the parent and not the
On Mon, 18 Dec 2017 17:48:27 -0500, Bob Arning <arning315 at comcast.net> wrote:
>On 12/18/17 3:43 PM, Louis LaBrunda wrote:
>> I do have a small problem that I find odd. If a picture
>> of one or more of the hands is not supplied I generate a default hand similar to what is used
>> in ClockDialMorph. The odd thing is that the rotation point is about 18 pixels above center.
>> pointerMorph position: pointerMorph extent * (-0.5 @ -0.95).
>> Any thoughts?
>You are using a different y-value (-0.95 vs -0.65) from the previous
>example. Is that the cause?
Keystone Software Corp.
More information about the Squeak-dev