heading = forwardDirection +etc (Ans to Andrew and Karl)

heading = forwardDirection + rotationDegrees (was Re:
How can we deal with Message rot?)

Hi Karl, Hi Andrew (see your reply below Karl's)

>karl karl.ramberg at chello.se
>Mon Jan 8 07:41:12 UTC 2007 added:
>
>Morphic has it's flaws...
>
>Morphic transformations were retrofitted and this was
kept trough the
>ages as no one found it compelling enough to refactor
Morphic to handle  
>transformations without using the TransformationMorph
stuff.
>
>Tweak is next generation Morphic, and is written to
handle
>transformation from the ground up, but it has less
users and less
>documentation etc...

Tweak polygons shrink when rotated. So I continue to
repair morphic and hope what ever I learn may be
ported to tweak if the tweak developers are so
motivated.

-----
Hi Andrew

Thanks for noticing my note.  I have done some work to
address the polygon rotation problem.
And I've been able to achieve some preliminary results

See Mantis:
http://bugs.impara.de/view.php?id=5498
Summary
0005498: Polygons don't render/orient submorphs
correctly when tilted or grown.

Which points to a work in progress milestone available
at:

http://209.143.91.36/super/724
PolyFix02-wiz


The keys are that reference positions for submorphs
need to be transformed similarly to the vertices of
polygons. And fixing polygons are not enough. There
are integration issues involved.

The invariants that need to hold true (in my user
story are)
1) heading = forwardDirection + rotationDegrees
2) What's placed at the reference point stays at the
reference point.
3) All morphs should "appear" to behave similarly when
rotated, scaled or grown.
4) When grabbed from or dropped into a morph the
grabbee/droppee should  always retain its apparent
location and appearence.

Mostly these don't happen across all morphs in squeak.
In many cases they don't happen in any morphs.

My approach is to keep these goals in mind as I do the
small repairs
and eventual try code that will effect the larger
repairs.

Along the way it will be interesting to see if the
community will "accept" the proposed changes.

>Andrew P. Black black at cs.pdx.edu
>Mon Jan 8 04:02:46 UTC 2007 wrote:  
>
<<much snipped>>

>Last night, I was trying to do a Morphic version of
Adele Goldberg's  
>"Joe the Box" as presented in Mark Guzdial's book.
Because I have  
>had students really confused by TransformationMorphs
(which break the  
>rule that every Morph is visible on the screen), I
made a "BoxMorph"  
>just a subclass of PolygonMorph with four vertices.
This worked  
>pretty well, except that rounding errors accumulate
as you rotate the  
>box;

There is a tradition of early and aggressive
rounding/truncation in morphic that seems to cause
cumulative rounding errors.
The solutions are to delay the conversion to integer
as long as possible and then to take care to do the
correct type of conversion.(floor or ceiling for
points, and sometimes expanded or compressed for
rectangles.)

> I couldn't think of a simple solution to that.  Then
I did  
>NamedBoxMorph, which puts a text morph containing the
Box's name  
>(joe, jill, etc) in the center of the Polygon.
>
>Well, as you rotate the Box, the text inside does
_not_ rotate.  This  
>is not what I expect from embedded submorphs.  It
turns out that  
>there is no code in PolygonMorph to rotate the
submorphs.  I think  
>that this is a bug,

Yep. It is see the mantis report. Help and attention
are needed to get it fixed.


>but writing the code involves more than I know.  
>(I did try.  Applying a MorphicTransformaiton to a
point is easy, but  
>applying it to a Morph --- that I couldn't figure
out.)
>Also, as you rotate the PolygonMorph, and morph at
its center refuses  
>to stay at the center.  It "precessses" towards the
origin and back.
Cumulative roundoff gribbles pretty much. And the
feedback loop between rotation and bounds and bounds
and center of rotations reference point.  That needs
both a local (for polygon) fix and a global rethink.
The polygons aren't too hard to fix. You define your
reference center as vertices average. If you don't
round when rotating that will stay in one place.
   
>Try it.  (My code is in a publicly readable
SqueakSource project at  
>http://www.squeaksource.com/PSUCS520 .  The package
is called CS520-
>MorphicBoxes).

I've downloaded this.
Will take a look when I have a chance. thanx.

>
>So I gave up, and tried a different approach, which I
have used  
>previously.   I made a BoxMorph2 a
TransformationMorph, with a  
>RectangleMorph inside it.  Both of them the same
size.   Easy to set  
>up, right?  Just give them the same bounds.  Wrong.
Even before they  
>are in any world, the TransformationMorph has resized
itself and has  
>changed it's scale factor to 1.7  

Wow that's a cool bug.

 May I suggest writing it up on mantis as a complaint.
Then its might gather clues from others or even a
solution.

I'm reduced to trial and error to  
>find an initialization sequence that works.  But when
I find one, the  
>BoxMorph2 can indeed be rotated.
>
>Then I put a TextMorph in the center  (myBoxMorph2
addMorphCentered:  
>aTextMorph).  All hell breaks loose.  The  label is a
couple of  
>inches down and to the right of the box.
blue-clicking on the box  
>puts the halo around the label.  I spend a long time
looking for this  
>bug, and find somewhere in the re-computation of the
bounds that  
>fullbounds of the BoxMorph2 has grown by a factor of
2 to 3 (but  
>different factors  in the x and y directions).   I'm
supposed to  
>explain this to studnets when I have no idea waht is
going on  
>myself.

Yeah, this one would be easier to fix than write the
manual for.
Things are getting added, The distance from owner
bounds topleft
to the unrotated added morph top left is being
maintained. (or something like that.)
I don't remember if the actual vector participates in
the transform or not.


  What did Dan Ingalls write about "personal mastery?"
>
>I eventually get it working by embedding the
TextMorph inside the  
>RectangleMorph (which is inside the Transformation
Morph).  Why does  
>it work this way around and not the other way?

tForm morphs are built to assume they will have only
one renderer.
They can of course have more but this screws up when
the assumption is relyed upon by some other piece of
code. Embedding in the rendee works better cause it
keeps the reedee/render ratio = 1.

  Beats me.  The code  
>is ugly because I use findA: to get hold of the
internal  
>RectangleMorph.  
morph renderedMorph will find the correct thingamabob.


(So, later I did see the comment that says:  
>"TransformationMorphs are assumed to have only one
submorph".  If  
>that's true, maybe one should get an error when an
attempt is made to  
>add a second one?)

Another good topic for mantis.
>
>I keep on thinking that Morphic is really elegant and
that all of  
>this will one day make sense if only I can learn to
squint in the  
>right way.  But I'm seriously beginning to wonder ...

I fell in love with morphic when I saw you could build
stuff by without writing a line of code just poking
and grappling with morphs.  
I learned the rest of squeak so I could make better
morphs to use without any deeper knowledge.
I'm still trying to find ways to make this happen.
Not only is it fun. But it still seems "The Way Its
'Spozed To Be."

It bothered me greatly as I came across ways the
implementation fell short of the goal.
But goal were its supposed to be. And the process to
get it there is up to those of us who care.

I've fixed polygons so they can stand in for ovals as
well as rectangle. I've got more fixes on the way
including the rotation fix.

>I would really like to know if I'm the only one who
feels this way.

I think there are a few. One problem is poor channels
of communication with the squeakland/OPLC side and
squeak-dev side. Or maybe just poor communication
between developers and users in general. It make there
seem to be fewer interested than really are.

>
>What to do about it?  I think that getting rid of  
>TransformationMorphs as wrappers (they are not really
decorators,  
>because they are not inserted into the Morphic
hierarchy until  
>something needs to be transformed) would help, and
instead giving  
>each Morph the ability to transform itself.  This
would involve a  
>test, of course: myTransformation ifNotNi: [ ... ]
which is a tad  
>ugly.

Two points.
On one side:
The wrapper is an optimizer( you rotate one image and
do no have to worry about the recursive rotation of
submorphs.) So it would be good to have them in good
working condition.

And on the alternative side:
Two the message could probably be beautiful.
aTransformation draw: aMorph on: aCanvas.
Identity transformations would know to do the simple
thing.
The others would take appropriate action or double
dispatch.
So a morph could always have a transformation
initialized using the identity transform as a default.

At this stage I leave myself open to both
possibilities till I see which is easiest to
repair/implement.




  This is similar to what was done with Alignment a
while back  
>--- giving every Morph the ability to align its
submorphs.  (However,  
>I think that that change may have been a mistake;
adding a separate  
>allignmentMorph to the hierarchy makes much more
sense to me than  
>adding a separate TransformationMorph.  Moreover, we
know that any 2-
>D affine transformation can be represented as a 3 x 2
matrix, so  
>there can be a single universal implementation of
transformations

Yep. So the third possibility is to make the Matrix3x2
stuff work accurately and correctly.
And maybe document it a little because it gets
complicated in practice.
>
>
>Andrew P. Black
>Department of Computer Science
>Portland State University
>+1 503 725 2411
>

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around
http://mail.yahoo.com 

On Jan 9, 2007, at 6:03 , Jerome Peace wrote:

> Tweak polygons shrink when rotated.

Actually, that was fixed in the tinlizzie version. You need a  
properly transforming canvas to make it work. RomeCanvas does this,  
which was made available last year.

> So I continue to
> repair morphic and hope what ever I learn may be
> ported to tweak if the tweak developers are so
> motivated.

There is not much development going on in basic Tweak at the moment.  
It's used in Croquet and Sophie, but the etoys developers' attention  
is at OLPC right now. Of course, it's up for everyone to take and  
improve.

We welcome fixes and improvements in the OLPC version. Like, most of  
the fixes posted by community members to the [hidden email] list  
actually went into the image. From our perspective it would make a  
lot of sense to base a future squeakland version on the OLPC etoys  
image. This is why only minimal efforts go into the current  
squeakland version which is nicely stable.

- Bert -