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