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



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20070107/cb4b3295/attachment.htm