I doing Squeak teaching to student's of my class.
They are about 20 years old and see something OOP and Smalltalk before using Smalltalk Express as part of his curricula.
When I show Squeak to them in lab , I took a EllipseMorph from flaps, duplicate several times , changing color via halo and to one of ellipses I do rotate via halo too.
I open a Workspace and type:
World submorphs do: [ :m| (m isKindOf: EllipseMorph ) ifTrue: [ m delete ].
Guess what:
The rotate one don't delete. I know what should be originate a TransformationMorph , so I pick again via halo and raise a inspector.
Surprise!! The inspectors says what still is a EllipseMorph.
Then I subclass Trash can and intercept dropping whit a self halt.
Now I see what morph dropped was TransformationMorph.
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"
And how I don't have clever answers ,here I asking to list what to say.
Edgar
On Thu, Sep 02, 2004 at 06:59:36AM -0300, Lic. Edgar J. De Cleene wrote:
I doing Squeak teaching to student's of my class.
They are about 20 years old and see something OOP and Smalltalk before using Smalltalk Express as part of his curricula.
When I show Squeak to them in lab , I took a EllipseMorph from flaps, duplicate several times , changing color via halo and to one of ellipses I do rotate via halo too.
I open a Workspace and type:
World submorphs do: [ :m| (m isKindOf: EllipseMorph ) ifTrue: [ m delete ].
Guess what:
The rotate one don't delete. I know what should be originate a TransformationMorph , so I pick again via halo and raise a inspector.
Surprise!! The inspectors says what still is a EllipseMorph.
Then I subclass Trash can and intercept dropping whit a self halt.
Now I see what morph dropped was TransformationMorph.
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"
And how I don't have clever answers ,here I asking to list what to say.
While I do think it passing strange that rotation causes a class-change (which I didn't realise was possible in Smalltalk), class-changing can be extremely useful. For instance, it allows one to add new methods to an object by creating a new class derived from the old class, then changing the class of the object. Of course, naive use has problems, and smalltalk may have better ways of doing that, but that is an example of a real use
On Sep 2, 2004, at 6:09 AM, Marcin Tustin wrote:
On Thu, Sep 02, 2004 at 06:59:36AM -0300, Lic. Edgar J. De Cleene wrote:
World submorphs do: [ :m| (m isKindOf: EllipseMorph ) ifTrue: [ m delete ].
Guess what:
The rotate one don't delete. I know what should be originate a TransformationMorph , so I pick again via halo and raise a inspector.
While I do think it passing strange that rotation causes aclass-change (which I didn't realise was possible in Smalltalk), class-changing can be extremely useful. For instance, it allows one to add new methods to an object by creating a new class derived from the old class, then changing the class of the object. Of course, naive use has problems, and smalltalk may have better ways of doing that, but that is an example of a real use
What is happening is that the owner of the ellipse morph changes from the world to a transformation morph. The class of the ellipse morph is not changing.
To see this open an inspector on an ellipse morph and display the owner category. You'll see it's the world. Now rotate the ellipse, you'll see the owner change to a transformation morph.
regards
On 02/09/04 12:12, "Frank Caggiano" frank@crystal-objects.com wrote:
What is happening is that the owner of the ellipse morph changes from the world to a transformation morph. The class of the ellipse morph is not changing.
To see this open an inspector on an ellipse morph and display the owner category. You'll see it's the world. Now rotate the ellipse, you'll see the owner change to a transformation morph.
regards
Frank: Very thanks. I know all this. I translating to list comments of Spanish students
The mail of Jecel is what I pick for class instructions of what happen in Squeak and is different as Smalltalk Express.
I don't like to tell them what inspectors of morphs not always pick the correct one ,
So , thanks to all, and as said to students, our list is friendly, quick and educative
Edgar
"Lic. Edgar J. De Cleene" edgardec2001@yahoo.com.ar wrote:
Now I see what morph dropped was TransformationMorph.
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"
And how I don't have clever answers ,here I asking to list what to say.
Edgar
Just by the way, the class of the object does not change. 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.
-Lex
On 02/09/04 14:01, "Lex Spoon" lex@cc.gatech.edu wrote:
Just by the way, the class of the object does not change. 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.
-Lex
Lex: I appreciate your answer and I know this. But the point is what when you pick the rotated ellipse via halo and raise one inspector, the inspector says "EllipseMorph" and this is what confused some people coming from other more single system like Smalltalk Express.
Cheers.
Edgar
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
On 02/09/04 14:26, "Jecel Assumpcao Jr" jecel@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
squeak-dev@lists.squeakfoundation.org
-
Edgar J. De Cleene -
Frank Caggiano -
Jecel Assumpcao Jr -
Lex Spoon -
Lic. Edgar J. De Cleene -
Marcin Tustin