[Etoys] [Fix] Horizontal and Vertical Flips

Scott Wallace scott.wallace at squeakland.org
Thu Feb 28 22:04:42 EST 2008

On Nov 14, 2007, at 11:46 AM, subbukk wrote:
> On Tuesday 13 November 2007 6:06 am, Scott Wallace wrote:
>> Hi, Subbu,
>> If the sketch has been rotated, this patch seems to produce incorrect
>> results.
> Here is my second attempt at getting Etoys to flip and tumble. The  
> flip
> command will do a left-right swap around the rotationCenter while  
> the tumble
> command will do a top-bottom swap.
> flip/tumble operations are not propagated to submorphs and I find  
> that a bit
> disconcerting with embedded morphs.

Hi, Subbu,

So sorry to have let this drop for so long.  I finally got around to  
taking a look at your "flipFixes.3.cs" fileout today.

It works nicely for unrotated Sketches.

As before, if "flip" or "tumble" is applied to a SketchMorph which has  
been *rotated*, there are surprising and (nearly) unpredictable visual  

I think (maybe) people would expect that sending "flip" to an objet  
seen on the screen, whether or not the object had previously been  
rotated, would horizontally flip the bits of *as seen on the screen*  
-- not the bits of a different, unseen, "original form".

But maybe I'm wrong -- perhpas there are cases where flipping the  
original form is closer to what the user expects.   Anyway,  
implementing what I suggest might be tricky and lossy.  A replacement  
"originalForm" would need to be deduced from the form obtained by  
flipping the bits of the rotated, scaled form.  Anyone care to try?

On balance, I think the "flip" and "tumble" features are useful for  
the kinds of examples you do; people will just need to know that they  
should be operating with *unrotated* Sketches if they want plausible  
results using flip and tumble.  They'd learn, I suppose.

So, arguably, we should incorporate your code in etoys3.0...?

However, having waited this long, let's wait just a little while  
longer, in case anyone cares to try his hand at an implementation that  
gives what I suggest to be the more intuitive result for sketches that  
have been rotated and resized, and/or, more ambitiously, for sketches  
which have embedded submorphs.

In hopes of stirring up a little more conversation on this ...

  -- Scott


> Turn left/right, grow/shrink/flip/tumble, shear left/right/forward/ 
> backward,
> move left/right/forward/backward transforms can be defined directly  
> on Morphs
> (+extensions). I am confused about the role and necessity of non- 
> visual
> morphs like TransformationMorphs and FlexMorphs. What specific  
> problem do
> these solve?

This was a design choice made in the very early days of morphic-in- 
squeak, 1997-8.  In practice, this has been a huge and unending -- and  
indeed ongoing, ten years later -- source of bugs.  The specific  
problem being solved was that there had not been enough complexity and  
confusion, and that there had been too few bugs.

More information about the Etoys mailing list