Squeak clock face

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
31 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: Squeak clock face

timrowledge

> On 18-12-2017, at 10:51 AM, Louis LaBrunda <[hidden email]> wrote:
>
> Hi Tim,
>
> Can you please explain what this does:

If I’m remembering properly (never a very good bet)

>
> pointerMorph position: pointerMorph extent * ( -0.5@ -0.65).

moves the pointerMorph so that its origin is moved so that the horizontal center ( 0.5 * width) is at x=0 and the vertical moves ~two thirds of the way up. Then when you add it to the transformationmorph the centers line up where you want it for rotating.

For this to work like that I made the graphic be the needle pointing vertically up.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
If it was easy, the hardware people would take care of it.



Reply | Threaded
Open this post in threaded view
|

Re: Squeak clock face

Bob Arning-2
In reply to this post by Louis LaBrunda


On 12/18/17 1:51 PM, Louis LaBrunda wrote:
> Hi Tim,
>
> Can you please explain what this does:
>
> pointerMorph position: pointerMorph extent * ( -0.5@ -0.65).
>
> especially what does "* ( -0.5@ -0.65)" do
multiplication of a point (extent) by another point (-0.5 @ -0.65) gives
a point as the result. The x-coords are multiplied together and the
y-coords similarly. In this case, the pointerMorph will be positioned
centered on 0 in the x axis (from -0.5 width to +0.5 width) and mostly
above 0 on the y axis (from -0.65 height to +0.35 height). This likely
will result in pleasing rotation about 0@0. Of course, you could put a
halt in the code and check this for yourself.

> and why and what do -0.5 and -0.65 relate to?
>
> Thanks.
>
> Lou
>
> On Fri, 15 Dec 2017 14:33:34 -0800, tim Rowledge <[hidden email]> wrote:
>
>>> On 15-12-2017, at 2:01 PM, Louis LaBrunda <[hidden email]> wrote:
>>>   I have sub-classed RotaryDialMorph similar to Tim's ClockDialMorph.  Tim has
>>> the hands (minute and hour) rotate around one of their ends.  I'm trying to get them to rotate
>>> around a point say 20 pixels in from that end.  How should I do this?
>> Take a look also at Barometer (etc) morph>>initialize to see how the fancy needle is created and positioned
>>
>>
>> tim


Reply | Threaded
Open this post in threaded view
|

Squeak clock face

Louis LaBrunda
Hi Bob and Tim,

Both your explanations were very helpful.  Thank you.  I am now able to read in a clock face
picture and pictures for the hour, minute and second hands.  I include how far from the end the
rotation point is.  This works great.  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.
This seems to correspond to the height of the menu bar in the main Squeak window.  But that
could just be a coincidence.

This is the code that makes a second hand:

makeSecondHandMorph
        "Make a default morph for the second hand."
        | pointerMorph |

        pointerMorph := self basicNeedleOfLength: (self height * 0.45) rounded width: 3 color: Color
red.
        pointerMorph position: pointerMorph extent * (-0.5 @ -0.95).

        "we keep track of the TransformationMorph since that is what we have to rotate"
        secondHandMorph := TransformationMorph new position: dialCenter; addMorph: pointerMorph.
        self addMorph: secondHandMorph.


and this code reads in a picture to be used as a second hand:

secondHandMorph: aFileName rotationOffset: offset
        "Set the morph for the second hand."
        | pic pointerMorph yOffset |

        pic := Form fromFileNamed: aFileName.
        pointerMorph := (self newPointerFrom: pic length: (self height * 0.45)) asMorph.
        yOffset := -1.0 + (offset / pic height).
        pointerMorph position: pointerMorph extent * (-0.5 @ yOffset).

        secondHandMorph := TransformationMorph new position: dialCenter; addMorph: pointerMorph.
        self addMorph: secondHandMorph.

again, the code that I would think would have a problem, the code that read in the picture,
works just fine.  The code that draws a simple line for the hand has the center of rotation too
high above the center.

By the way, #dialCenter is sent to the center of the clock with self center.

Any thoughts?

Lou


On Mon, 18 Dec 2017 14:15:02 -0500, Bob Arning <[hidden email]> wrote:

>
>
>On 12/18/17 1:51 PM, Louis LaBrunda wrote:
>> Hi Tim,
>>
>> Can you please explain what this does:
>>
>> pointerMorph position: pointerMorph extent * ( -0.5@ -0.65).
>>
>> especially what does "* ( -0.5@ -0.65)" do
>multiplication of a point (extent) by another point (-0.5 @ -0.65) gives
>a point as the result. The x-coords are multiplied together and the
>y-coords similarly. In this case, the pointerMorph will be positioned
>centered on 0 in the x axis (from -0.5 width to +0.5 width) and mostly
>above 0 on the y axis (from -0.65 height to +0.35 height). This likely
>will result in pleasing rotation about 0@0. Of course, you could put a
>halt in the code and check this for yourself.
>
>> and why and what do -0.5 and -0.65 relate to?
>>
>> Thanks.
>>
>> Lou
>>
>> On Fri, 15 Dec 2017 14:33:34 -0800, tim Rowledge <[hidden email]> wrote:
>>
>>>> On 15-12-2017, at 2:01 PM, Louis LaBrunda <[hidden email]> wrote:
>>>>   I have sub-classed RotaryDialMorph similar to Tim's ClockDialMorph.  Tim has
>>>> the hands (minute and hour) rotate around one of their ends.  I'm trying to get them to rotate
>>>> around a point say 20 pixels in from that end.  How should I do this?
>>> Take a look also at Barometer (etc) morph>>initialize to see how the fancy needle is created and positioned
>>>
>>>
>>> tim
>
>
--
Louis LaBrunda
Keystone Software Corp.
SkypeMe callto://PhotonDemon


Reply | Threaded
Open this post in threaded view
|

Squeak clock face

Louis LaBrunda
In reply to this post by Javier Diaz-Reinoso
Hi Javier,

Thanks for the help.  The movie did post and look good.  I am presently trying Tim and Bob's
suggestions with some success.

Lou

>Well, I think is for eToys Players and in that works well, to test use this in workspace:
>
>attrs := {{100 . Color red . 0.5@0.5} . {200 . Color blue . 0.25@0.25}}..
>hands := attrs collect: [:att| |lm|
> lm := LineMorph from: 150@300 to: (Point x: 150+(att at:1) y: 300) color: (att at: 2) width: 2.
> lm rotationCenter: (att at: 3).
> lm makeForwardArrow].
>hands do: [:m | m openInWorld].
>
>and then create 2 (eToy) scripts to rotate, I am enclosing a movie (344kb), I hope is not rejected:
--
Louis LaBrunda
Keystone Software Corp.
SkypeMe callto://PhotonDemon


Reply | Threaded
Open this post in threaded view
|

Re: Squeak clock face

Bob Arning-2
In reply to this post by Louis LaBrunda


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?

Reply | Threaded
Open this post in threaded view
|

Squeak clock face

Louis LaBrunda
Hi Bob,

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

Lou

On Mon, 18 Dec 2017 17:48:27 -0500, Bob Arning <[hidden email]> 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?
>
--
Louis LaBrunda
Keystone Software Corp.
SkypeMe callto://PhotonDemon


Reply | Threaded
Open this post in threaded view
|

Re: Squeak clock face

Bob Arning-2

The setting and later reporting of position are not different and this is a cause of occasional errors. If you have

MorphA>>initialize

    self addMorph: (MorphB new position: 1@1)


then B will be positioned one pixel from the top left of A. If, however, you do

    self addMorph: (MorphB new position: 1@1)

sometime later after A has been added to the World and possibly moved, then you may get something different, like B being one pixel from the Display top left, regardless of where A is currently. If that is the case, and, maybe, as a general precaution, then


    self addMorph: (MorphB new position: 1@1 + self position)

would be more robust.


On 12/19/17 11:41 AM, Louis LaBrunda wrote:
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
screen.



Reply | Threaded
Open this post in threaded view
|

Re: Squeak clock face

Javier Diaz-Reinoso
In reply to this post by Louis LaBrunda
The reason my example works is because I am rotating a Polygon, the problem is with ImageMorphs/SketchMorphs, and the selector with problems is TransformationMorph>>adjustAfter: of 'ar 1/3/2010' created in Squeak 3.11, If you revert to the previous version of: 'di 9/30/1998' works OK.

Also works if you create an (eToys) script with Player>>turn: because that copy the actorStateOrNil to the transformMorph which the new version expect.

Because the new version was from 'ar' you know that was created for some important reason, so is any documentation for the change?

> On 18 Dec 2017, at 15:45, Louis LaBrunda <[hidden email]> wrote:
>
> Hi Javier,
>
> Thanks for the help.  The movie did post and look good.  I am presently trying Tim and Bob's
> suggestions with some success.
>
> Lou
>
>> Well, I think is for eToys Players and in that works well, to test use this in workspace:
>>
>> attrs := {{100 . Color red . 0.5@0.5} . {200 . Color blue . 0.25@0.25}}..
>> hands := attrs collect: [:att| |lm|
>> lm := LineMorph from: 150@300 to: (Point x: 150+(att at:1) y: 300) color: (att at: 2) width: 2.
>> lm rotationCenter: (att at: 3).
>> lm makeForwardArrow].
>> hands do: [:m | m openInWorld].
>>
>> and then create 2 (eToy) scripts to rotate, I am enclosing a movie (344kb), I hope is not rejected:
> --
> Louis LaBrunda
> Keystone Software Corp.
> SkypeMe callto://PhotonDemon
>
>


Reply | Threaded
Open this post in threaded view
|

Squeak clock face

Louis LaBrunda
In reply to this post by Bob Arning-2
Hi Bob,

Thanks for the hint about:

     self addMorph: (MorphB new position: 1@1 + self position)

Because I am loading images for the clock face and hands, I have had to do the loading and
definition of the morphs after the #initialize method has exited.  Also, I am only drawing
clock hands if they are not loaded from images.  I have added a #setReady that declares the
clock ready to be opened.  I was lazily initializing the hands.  If a drawn hand was used and
not an picture, this would happen after the clock was opened in world (#openInWorld).  That
caused the rotation point to be off.  I have changed #setReady (which should be called before
#openInWorld) draw the hands if need be.  That puts the rotation point of the hands in the
right spot in all cases.

As far as the setting and later reporting of position not being different, I will take your
word for it.  But it does seem to me that before being open in world, position is 0@0 offset
and after words it is offset to the screen.

Thanks again.

Lou

On Tue, 19 Dec 2017 12:30:13 -0500, Bob Arning <[hidden email]> wrote:

>The setting and later reporting of position are not different and this
>is a cause of occasional errors. If you have
>
>MorphA>>initialize
>
>     self addMorph: (MorphB new position: 1@1)
>
>
>then B will be positioned one pixel from the top left of A. If, however,
>you do
>
>     self addMorph: (MorphB new position: 1@1)
>
>sometime later after A has been added to the World and possibly moved,
>then you may get something different, like B being one pixel from the
>Display top left, regardless of where A is currently. If that is the
>case, and, maybe, as a general precaution, then
>
>
>     self addMorph: (MorphB new position: 1@1 + self position)
>
>would be more robust.
>
>
>On 12/19/17 11:41 AM, Louis LaBrunda wrote:
>> 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
>> screen.
--
Louis LaBrunda
Keystone Software Corp.
SkypeMe callto://PhotonDemon


Reply | Threaded
Open this post in threaded view
|

Re: Squeak clock face

Bob Arning-2

It is 0@0 in the beginning. If you have a squeak menubar, then the clock morph will be *moved* down automagically when you add it to the World. That's why you were seeing the center off by the height of the menubar. If you were to turn off the menubar, then this problem would likely go away. As I mentioned, if you always adjust your relative positions by the owner morph's current position, the problem will also go away.


On 12/19/17 4:05 PM, Louis LaBrunda wrote:
As far as the setting and later reporting of position not being different, I will take your
word for it.  But it does seem to me that before being open in world, position is 0@0 offset
and after words it is offset to the screen.



Reply | Threaded
Open this post in threaded view
|

Re: Squeak clock face

Bob Arning-2
In reply to this post by Javier Diaz-Reinoso

The only comment I see associated with this change is

Make Etoys unloadable: Move lots of methods to Etoys package. Remove the old Fabrik remnants.

which applies to the whole change set (or Morphic-ar.294 if you prefer). What I think happened was this

-- it used to say:

    self penUpWhile: [self position: self position + (oldRefPos - self referencePosition)].
 
-- #penUpWhile was moved to the Etoys package

-- so that this would not blow up if there were no Etoys loaded, a guard was added:

    self actorStateOrNil ifNotNil:[
        self penUpWhile: [self position: self position + (oldRefPos - self referencePosition)].
    ].

-- the assumption being, I guess, was that only Etoys cared about rotation done this way


On 12/19/17 3:29 PM, Javier Diaz-Reinoso wrote:
The reason my example works is because I am rotating a Polygon, the problem is with ImageMorphs/SketchMorphs, and the selector with problems is TransformationMorph>>adjustAfter: of 'ar 1/3/2010' created in Squeak 3.11, If you revert to the previous version of: 'di 9/30/1998' works OK.

Also works if you create an (eToys) script with Player>>turn: because that copy the actorStateOrNil to the transformMorph which the new version expect.

Because the new version was from 'ar' you know that was created for some important reason, so is any documentation for the change?

On 18 Dec 2017, at 15:45, Louis LaBrunda [hidden email] wrote:

Hi Javier,

Thanks for the help.  The movie did post and look good.  I am presently trying Tim and Bob's
suggestions with some success.

Lou

Well, I think is for eToys Players and in that works well, to test use this in workspace:

attrs := {{100 . Color red . [hidden email]} . {200 . Color blue . [hidden email]}}..
hands := attrs collect: [:att| |lm|
	lm := LineMorph from: 150@300 to: (Point x: 150+(att at:1) y: 300) color: (att at: 2) width: 2.
	lm rotationCenter: (att at: 3). 
	lm makeForwardArrow].
hands do: [:m | m openInWorld].

and then create 2 (eToy) scripts to rotate, I am enclosing a movie (344kb), I hope is not rejected:
-- 
Louis LaBrunda
Keystone Software Corp.
SkypeMe callto://PhotonDemon






12