On Thursday 02 September 2004 06:59, Lic. Edgar J. De Cleene wrote:
> Guess what:
>
> The rotate one don't delete. I know what should be originate a
> TransformationMorph ,

Correct. Try doing "explore it" for the expression "World submorphs".

> so I pick again via halo and raise a inspector.
>
> Surprise!! The inspectors says what still is a EllipseMorph.

The behavior of halos is inconsistent in the case of 
TransformationMorphs, so you got the object which was the single 
submorph (the EllipseMorph in this case) instead of the parent morph as 
you expected.

> Then I subclass Trash can and intercept dropping whit a self halt.
>
> Now I see what morph dropped was TransformationMorph.

Which is correct.

> They says to me what this is "lack of consistency" and " a real
> object don't should change class by the fact you rotate it"

There was no change of class (though you can do that in Smalltalk - see 
#become: and others for examples), but you are right about the lack of 
consistency.

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