Squeak clock face

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

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.

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:
--
Louis LaBrunda
Keystone Software Corp.
SkypeMe callto://PhotonDemon

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
--
Louis LaBrunda
Keystone Software Corp.
SkypeMe callto://PhotonDemon

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?

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: --
Louis LaBrunda
Keystone Software Corp.
SkypeMe callto://PhotonDemon

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.

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.

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?

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:
--
Louis LaBrunda
Keystone Software Corp.
SkypeMe callto://PhotonDemon

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.

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.

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

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