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.