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.

Scott, Thanks for trying out the patch. I should have included a warning in my post. The patch only adds flip commands to the viewer of a SketchMorph. The SketchMorph methods themselves are broken. I use the patch to compose sketches with mirror symmetry and then grab the composite for a single sketch. Kludgy, but a stop gap till etoys get true transformation capabilities.

Flips don't work on rotated sketches because the flip* methods of SketchMorph are broken. They switch the form (which resets the rotationCenter) :-(. Rotations, flips, shear and scale, being views on the base image, should affect only the view transform values and not the base form.

Let me see if I can come up with a patch that will fix this. Subbu

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.

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?

Regards .. Subbu

On Tuesday 13 November 2007 9:59 pm, Bert Freudenberg wrote:

...

Flips don't work on rotated sketches because the flip* methods of SketchMorph are broken. They switch the form (which resets the rotationCenter) :-(. Rotations, flips, shear and scale, being views on the base image, should affect only the view transform values and not the base form.

Sounds useful to get in for Update.2 - please open a Trac ticket.

Done. Ticket #4969. I don't have access to XO. I would appreciate if anyone with XO can try out the fixes.

Subbu

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.