Put a newly created EllipseMorph on the desktop and rotate it. Then 
inspect it through its halo. The inspector will only indirectly show that 
a TransformationMorph got inserted between PasteUpMorph and EllipseMorph, 
because it gets opened for the EllipseMorph and not the 
TransformationMorph.

The ellipse morph gets wrapped by a TransformationMorph.

The system then goes to some lengths, apparently, to make it appear that 
this has not happened.  But it has, and certain ways of probing the system 
will let you see it.

Nobody likes this situation, and it seems likely to change in future 
Squeak graphics systems.  Class Morph just needs to have an optional 
transformation attached to it.

---

There are two opposite philosophies of GUI frameworks. On one extreme you 
have the "deep tree" approach of GraphPak (the graphic library created for 
Objective-C by Stepstone Corp.) where an ellipse would include only the 
sizes of its two axis and nothing more. If you want it at somewhere other 
than the origin, then place it in a transform wrapper. If you want a 
different color, place it in a color wrapper. And so on. So each thing you 
see on the screen is actually the root of a tree of nested objects with 
half a dozen elements or more.

Advantages of this solution:

 - the little pieces can be combined in many ways that the original 
   authors might not have considered

 - you can set up complex graphs to express things such as "buttons 1 and 
   2 always have the same color, button 3 currently also has that color 
   but can be changed independently of the other two"

 - new little pieces can be added to the framework and they apply 
   uniformly to all previous stuff without requiring any changes to them

Problems:

 - most of the objects have only an indirect visual representation, so 
   direct manipulation becomes complicated

 - your carefully constructed object tree/graph will be wrong more often 
   than right for what you want to do right now, so you will have to do a 
   lot of rearranging before being able to start the task you are actually 
   interested in

Direct manipulation was the main motivation behind Morphic in Self, so the 
"big, fat object" model was chosen instead. One additional advantage of 
the "deep tree" solution is that it partly compensates for the limitations 
of class based languages but Self was prototype based so there was no 
interest in that. In Morphic, each visual object corresponds directly to a 
single language level object which handles all the needed details. The 
only exception is the morph/submorph composition scheme, but that 
corresponds directly to the visual hierarchy and isn't a problem for users.

When Morphic came to Squeak, it had to be compatible to a certain extent 
with MVC applications and to be the base for a scripting system (eToys). 
So "big" and "fat" became much more so. With Warpblit (and later Balloon) 
the lack of scaling and rotation in Morphic became unacceptable. One 
alternative would be to make every single morph even fatter by including 
its own transformation. Given that this would be only rarely used, using a 
separate wrapper object (TransformationMorph) was a better choice. But it 
was an inconsistent choice!

I see no better solution with Squeak as it is, so for now you will just 
have to deal with this: morphs are all visible and independent, except 
when they aren't.

-- Jecel