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

Hi Bert,

Thanks for your thought on this.

>Bert Freudenberg bert at freudenbergs.de 
>Wed Dec 27 14:14:12 UTC 2006 wrote:
>
>On Dec 27, 2006, at 6:36 , Jerome Peace wrote:
>>  more details of the heading etc. confusion
>> can be found mantis
>>
>> http://bugs.impara.de/view.php?id=5674
>>
>> 0005674: Why doesn't heading = forwardDirection +
>> rotationDegrees for all morphs all the time?
>
>As far as I know, rotation and animation (that is,
LOGO-style turtle  
>semantics) is only seriously used in Etoys.

I think it only seems this way.

First, I am making the assumption that by eToys you
are refering to programming with tiles, Players etc.

The larger realm of eToys also consists of morphs and
their behavior (particular behavior in response to
halo handles).  So what affects programming with tiles
spills over into morph considerations.

 
>For most other UI users  
>it's merely a gimmick, so you would not need to worry
about backwards  
>compatibility too much. 

Ok. thanx.



>Etoys uses a very small set of messages  
>(manifest in the Player class). As long as you ensure
this small  
>protocol does not break, Etoys should be fine.
>
>Now, Player is very careful to always figure out the
"right" morph to  
>apply rotations to, depending on whether it wants to
be "flexed" (in  
>a TransformMorph) or if it handles rotation itself
etc.

Etoys player would benifit greatly from knowing less
about how a morph carries out its tilting
responsibilities. That means establishing a consistent
language and having all classes (and their programmers
and maintainers) stick to it.

This is the task of an oft promised but long overdue
refactoring of morphic stuff.

I haven't worked out the details but the notion I have
is that it should be possible to say

"player assuredFlexibleCostume heading: aHeading "   

and have the right thing happen.


And maybe later
"player assuredSimplestCostume"

which would remove redundant renderers. 
 

>This is why  
>you see inconsistent behavior in the individual morph
classes.

But it shouldn't be that way.  The responsibilities
can be clearly defined and every morph would benifit. 


Many of the deep bugs I run into have the
TransformationMorph decorator as their root.
Lots of the gribble leaving problems come from a
mismatch of assumptions between TfMorph ( which
believes you can translate the origin into the 3rd
quadrant) while every body else believes that truncate
is the same as floor  because all points are in the
1st quadrant. Clipping boxes get calculated wrong and
are often of by one just when you need them not to be.


Results: screen gribbles abound.  

>- inEtoys they are not used directly, but through the
Player, and this is  
>why your equation does not hold for each individual
morph. I think  
>you would have to eliminate TransformMorph
completely, which might  
>complicate other Morphs - until now, that "ugly"
transformation stuff  
>was factored out.

As I look at the code I see constant attempts to worry
about which morph is actually being talked to renderer
or renderee. The code practically begs to be
refactored. Its just a big job at the moment.
I await enlightenment and inspiration. Meanwhile I am
trying refactorings that lay the ground work for the
simplification of the Tf mess.

Yours in service, --Jerome Peace

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