[Etoys] [Fix] Horizontal and Vertical Flips

[Scott Wallace]

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  
results.

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


PS:

> 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.