So, last night, having been fighting Morphic for about 5 hours (trying to write a really, really simple example for my first class), I was about to write a flame "why I hate Morphic and what we should do about it". But I went to sleep instead.

And now I notice this from Jerome:

On 2 Jan 2007, at 6:33, Milan Zimmermann wrote:

On 2006 December 29 01:27, Jerome Peace wrote: <<snip>>

...

Many of the deep bugs I run into have the TransformationMorph decorator as their root. Lots of the gribble leaving problems come from a mismatch of assumptions between TfMorph ( which believes you can translate the origin into the 3rd quadrant) while every body else believes that truncate is the same as floor because all points are in the 1st quadrant. Clipping boxes get calculated wrong and are often of by one just when you need them not to be.

Jerome,

Could you point out a few concrete examples (class, method) of this behaviour? I started work on a (exteremely limited) set of tests for etoys and morphic, and perhaps it would make sense to document what you found in a test; although documenting something that is (if I understand) considered broken may not be as valuable, it should be easy to convert the test code if/once the code under test is refactored.

Thanks Milan

Transformations are indeed the core of the problem. It has often seemed to me that all morphs should be able to take care of their own transformations, rather than having to be embedded in a TransformationMorph.

Last night, I was trying to do a Morphic version of Adele Goldberg's "Joe the Box" as presented in Mark Guzdial's book. Because I have had students really confused by TransformationMorphs (which break the rule that every Morph is visible on the screen), I made a "BoxMorph" just a subclass of PolygonMorph with four vertices. This worked pretty well, except that rounding errors accumulate as you rotate the box; I couldn't think of a simple solution to that. Then I did NamedBoxMorph, which puts a text morph containing the Box's name (joe, jill, etc) in the center of the Polygon.

Well, as you rotate the Box, the text inside does _not_ rotate. This is not what I expect from embedded submorphs. It turns out that there is no code in PolygonMorph to rotate the submorphs. I think that this is a bug, but writing the code involves more than I know. (I did try. Applying a MorphicTransformaiton to a point is easy, but applying it to a Morph --- that I couldn't figure out.) Also, as you rotate the PolygonMorph, and morph at its center refuses to stay at the center. It "precessses" towards the origin and back. Try it. (My code is in a publicly readable SqueakSource project at http://www.squeaksource.com/PSUCS520 . The package is called CS520- MorphicBoxes).

So I gave up, and tried a different approach, which I have used previously. I made a BoxMorph2 a TransformationMorph, with a RectangleMorph inside it. Both of them the same size. Easy to set up, right? Just give them the same bounds. Wrong. Even before they are in any world, the TransformationMorph has resized itself and has changed it's scale factor to 1.7 I'm reduced to trial and error to find an initialization sequence that works. But when I find one, the BoxMorph2 can indeed be rotated.

Then I put a TextMorph in the center (myBoxMorph2 addMorphCentered: aTextMorph). All hell breaks loose. The label is a couple of inches down and to the right of the box. blue-clicking on the box puts the halo around the label. I spend a long time looking for this bug, and find somewhere in the re-computation of the bounds that fullbounds of the BoxMorph2 has grown by a factor of 2 to 3 (but different factors in the x and y directions). I'm supposed to explain this to studnets when I have no idea waht is going on myself. What did Dan Ingalls write about "personal mastery?"

I eventually get it working by embedding the TextMorph inside the RectangleMorph (which is inside the Transformation Morph). Why does it work this way around and not the other way? Beats me. The code is ugly because I use findA: to get hold of the internal RectangleMorph. (So, later I did see the comment that says: "TransformationMorphs are assumed to have only one submorph". If that's true, maybe one should get an error when an attempt is made to add a second one?)

I keep on thinking that Morphic is really elegant and that all of this will one day make sense if only I can learn to squint in the right way. But I'm seriously beginning to wonder ...

The good news is that the final code is really short and sweet, comparing well with the "draw on the raw screen" version that mark Guzdial puts in his book (Package "Boxes" in the same SqueakSource project, if you care to look). The bad news is that it is extremely brittle. I liek telling students to play with stuff an see what happens, and then to figure out why. I get the feeling that changing the order of two statements in this code might just as well precipitate the next revolution as change the stacking order of two Morphs ... and I have _no idea_ why.

OK, so now I'm just venting. But I would really like to know if I'm the only one who feels this way.

What to do about it? I think that getting rid of TransformationMorphs as wrappers (they are not really decorators, because they are not inserted into the Morphic hierarchy until something needs to be transformed) would help, and instead giving each Morph the ability to transform itself. This would involve a test, of course: myTransformation ifNotNi: [ ... ] which is a tad ugly. This is similar to what was done with Alignment a while back --- giving every Morph the ability to align its submorphs. (However, I think that that change may have been a mistake; adding a separate allignmentMorph to the hierarchy makes much more sense to me than adding a separate TransformationMorph. Moreover, we know that any 2- D affine transformation can be represented as a 3 x 2 matrix, so there can be a single universal implementation of transformations

Andrew P. Black Department of Computer Science Portland State University +1 503 725 2411