On 02/09/04 14:26, "Jecel Assumpcao Jr" <jecel at merlintec.com> wrote:

> 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
> 
Jecel:
Very thanks:
Today I show answers of you and Lex to students.
So they see what quick , friendly and educative our community is (what's I
always know)

Edgar