[Etoys] [Fix] Horizontal and Vertical Flips
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
> Here is my second attempt at getting Etoys to flip and tumble. The
> 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.
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 ...
> Turn left/right, grow/shrink/flip/tumble, shear left/right/forward/
> move left/right/forward/backward transforms can be defined directly
> on Morphs
> (+extensions). I am confused about the role and necessity of non-
> 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-dev