[Etoys] #7744 NORM Future : Rotated morph loses rotation on save

[Scott Wallace]

On Aug 3, 2008, at 10:37 PM, K. K. Subramaniam wrote:
> On Friday 01 Aug 2008 8:22:01 pm Zarro Boogs per Child wrote:
>>  I'm not sure this is a bug and not a feature ... It's easy enough to
>>  rotate a morph when brought into another project?
> Rotation center is saved in the file but not the rotation value  
> itself. So how
> would the code loading the morph know how much to rotate?
>
> If a morph is embedded in another morph, the submorph's rotation  
> does get
> restored when the owner morph is loaded from file. I realize why  
> this happens
> but the result is not consistent.
>
> This raises a deeper question. Are rotation and scaling an inherent,
> persistent property of the morph (like color or extent) or a transient
> property (like its origin or owner). If the latter, then why should  
> a flex
> wrapper persist after the rotation/scaling is ended? We could use a  
> single
> rubberband handle to rotate/scale and cache (heading,scale,graphic)  
> in an
> extension.

To my mind, rotation and scaling *are*, or should be, considered  
persistent properties of the morph, and thus the fact that they are  
not preserved when the morph is saved, stand-alone fashion, in  
a .morph file, is a bug -- minor, but still a bug.

But note that stand-alone saving in a .morph is not part of the "etoys  
interface", which is why it's hidden off in the debug menu,  
unavailable to "eToyFriendly" users.  The lone persistence mechanism  
that is formally supported in the etoys interface for kids is the  
project-saving mechanism.

   -- Scott