Should all sibling instances of a morph (in etoys-dev.image) respond to the same script? If this is so, I'm not sure that this is working correctly with EllipseMorph.
- Mark
Hello,
All siblings of same morph share same scripts. (not slots) You can use duplication instead of sibling. Each duplicated morph has individual scripts.
Regards, Kazuhiro Abe
2008/4/12, polishookm polishookm@mail.montclair.edu:
Should all sibling instances of a morph (in etoys-dev.image) respond to the same script? If this is so, I'm not sure that this is working correctly with EllipseMorph.
- Mark
On 11.04.2008, at 18:16, polishookm wrote:
Should all sibling instances of a morph (in etoys-dev.image) respond to the same script? If this is so, I'm not sure that this is working correctly with EllipseMorph.
I'm not sure if this is a problem, but you get the terminology mixed up, which may hinder understanding.
In Etoys you do not actually script a "morph". The script belongs to a "player", which "wears" a morph as its "custome". So you actually have siblings of a player, not of a morph.
Anyway, siblings should work independently of the costume. Please report the steps so we can reproduce the problem.
- Bert -
Ok. Trying my hand with proper terminology ...
I have a player that's wearing an ellipseMorph. The player script is below. I"m thinking that through a halo on the ellipseMorph, I can click on the green duplicate icon to get a second ellipseMorph that responds to the same script. But the sibling player doesn't then respond to the script.
I'm fairly sure, on the other hand, that I have been able to apply the same idea successfully to sketchMorphs. So that's the larger context of my question.
Thanks in advance for all help ....
- Mark
move (self getScaleFactor eToysLT: 0.5) ifTrue: [self setScaleFactor: 10.0 random / 10] ifFalse: [self setScaleFactor: 0.25]. self setDotSize: 6 random. self setPenColor: (Color r: 1.0 g: 1.0 b: 0.0). self setTrailStyle: #dots. self setPenDown: true. Polygon1 setPenDown: true. Polygon1 setTrailStyle: #dots. Polygon1 setDotSize: 3. self forward: 32 random. self turn: 32 random
Bert Freudenberg wrote:
On 11.04.2008, at 18:16, polishookm wrote:
Should all sibling instances of a morph (in etoys-dev.image) respond to the same script? If this is so, I'm not sure that this is working correctly with EllipseMorph.
I'm not sure if this is a problem, but you get the terminology mixed up, which may hinder understanding.
In Etoys you do not actually script a "morph". The script belongs to a "player", which "wears" a morph as its "custome". So you actually have siblings of a player, not of a morph.
Anyway, siblings should work independently of the costume. Please report the steps so we can reproduce the problem.
- Bert -
Etoys mailing list Etoys@lists.laptop.org http://lists.laptop.org/listinfo/etoys
To answer my own question, I think what I'm observing is noted below. If someone could comment that what I'm describing is how things work, that would be great.
1. I make an EllipseMorph 2. I open a viewer on the EllipseMorph and make a script. The script belongs to a Player and the Player wears the EllipseMorph 3. I bring up a halo on the EllipseMorph and click on the green Duplicate icon. 4. Now I have 2 Players, each of which wears an EllipseMorph 5. Opening an AllScriptsTool provides for start/stop/stop control over both Players
6. I make a RectangleMorph 7. I open a viewer on the RectangleMorph and make a script. The script belongs to a Player and the Player wears the EllipseMorph 8. I bring up a halo on the RectangleMorph and shift-click on the green Duplicate icon. 9. Now I have 1 Player that's wearing (controlling) 2 RectangleMorphs. 10. Opening an AllScriptsTool provides for start/stop/stop control over the Player that wears the 2 RectangleMorphs
I'm noticing that if AllScripts tool is on screen while EllipseMorphs or RectangleMorphs are being duplicated, it won't then immediately pick up on the fact that new Players exist. A new Player has to be run once and then the AllScriptsTool knows it's there.
Unrelated: The goldBoxIconSize-sw change, as noted in the change sorter, produces larger but fuzzy looking icons in the Gold Menu.
Thanks in advance for all explanation and help ....
Bert Freudenberg wrote:
On 11.04.2008, at 18:16, polishookm wrote:
Should all sibling instances of a morph (in etoys-dev.image) respond to the same script? If this is so, I'm not sure that this is working correctly with EllipseMorph.
I'm not sure if this is a problem, but you get the terminology mixed up, which may hinder understanding.
In Etoys you do not actually script a "morph". The script belongs to a "player", which "wears" a morph as its "custome". So you actually have siblings of a player, not of a morph.
Anyway, siblings should work independently of the costume. Please report the steps so we can reproduce the problem.
- Bert -
Etoys mailing list Etoys@lists.laptop.org http://lists.laptop.org/listinfo/etoys
On 13.04.2008, at 08:20, polishookm wrote:
- I bring up a halo on the EllipseMorph and click on the green
Duplicate icon.
- I bring up a halo on the RectangleMorph and shift-click on the
green Duplicate icon.
Clicking the green handle creates a copy, shift-clicking a sibling.
- Bert -
Bert Freudenberg wrote:
On 13.04.2008, at 08:20, polishookm wrote:
- I bring up a halo on the EllipseMorph and click on the green
Duplicate icon.
- I bring up a halo on the RectangleMorph and shift-click on the
green Duplicate icon.
Clicking the green handle creates a copy, shift-clicking a sibling.
I think I'm now clear about this but I'm not sure that current documentation or the user interface makes the meaning of this totally apparent. I say this in part because of the way that the AllTool morph interacts with copied and sibling scripts - in particular, the scenario where AllTools is probably best brought into the picture only after all copies or siblings have been made - rather than during or before the copy/sibling process.
- Bert -
Etoys mailing list Etoys@lists.laptop.org http://lists.laptop.org/listinfo/etoys
On Apr 13, 2008, at 8:20 AM, polishookm wrote:
To answer my own question, I think what I'm observing is noted below. If someone could comment that what I'm describing is how things work, that would be great.
Hi, Mark,
Basically, your observations are correct, but please see the comments after #9 and #10.
- I make an EllipseMorph
- I open a viewer on the EllipseMorph and make a script. The script
belongs to a Player and the Player wears the EllipseMorph 3. I bring up a halo on the EllipseMorph and click on the green Duplicate icon. 4. Now I have 2 Players, each of which wears an EllipseMorph 5. Opening an AllScriptsTool provides for start/stop/stop control over both Players
- I make a RectangleMorph
- I open a viewer on the RectangleMorph and make a script. The script
belongs to a Player and the Player wears the EllipseMorph 8. I bring up a halo on the RectangleMorph and shift-click on the green Duplicate icon. 9. Now I have 1 Player that's wearing (controlling) 2 RectangleMorphs.
Almost... What you now have are two *sibling players*, each of which is a "Player" in its own right. Each players wears its own separate RectangleMorph as its costume. The siblings are related in that they have (and will forever have) the same "shape" (i.e. each has the same list of "variables") and in that they share (and will forever share) the same scripts. If you add a variable to one of them, the same variable will be added to the other. If you add a script to one of them, the same script will apply to the other one.
But although siblings share a script, each sibling has its own private "status" for that script, i.e. remembers separately whether the script *as used by this instance* is "normal", "paused,", or "ticking", or set to trigger on mouse-up, etc.; and what the tick-rate is.
When using siblings, what's really happening underneath is that there is a custom Player "Class" is created to bear the shared code, and the siblings are individual "Instances" of that class. "Class" and "Instance" are among the most fundamental concepts of object-oriented programming, but we don't much use the terms "class" and "instance" in the etoys UI, nor in any documentation I'm aware of. (A notorious exception is the "all instances" checkbox in the all-scripts tool.) We refer to "siblings" but don't have a formal term for the "class". Hmm... maybe the checkbox should read "all siblings" rather than "all instances"...
- Opening an AllScriptsTool provides for start/stop/stop control
over the Player that wears the 2 RectangleMorphs
If the "all instances" box is not checked, you'll see the scripts for only one player of each sibling group. This will give you "control" over the scripts of only one of the players. If you want to be able to "control" scripts for both of the siblings, make sure the "all instances" checkbox is checked.
I'm noticing that if AllScripts tool is on screen while EllipseMorphs or RectangleMorphs are being duplicated, it won't then immediately pick up on the fact that new Players exist. A new Player has to be run once and then the AllScriptsTool knows it's there.
Unless the "all instances" checkbox is checked, creation of new siblings will typically not result in any noticeable change in the all- scripts tool, since all the scripts of the new sibling will already be represented by another instance in the tool. Perhaps that's what you're seeing.
Also, if the "tickers only" box is checked, only scripts whose status is "ticking" or "paused' are shown in the all-scripts tool. This can be another reason why the all-scripts tool may seem not to be "picking up" on a change.
AFAIK, it's fine to have an all-scripts tool open as you create, delete, rename, and otherwise manipulate objects and scripts; I'm not aware of situations where it "misses" anything, but if you can describe a sequence of steps leading to such a situation, it would be helpful.
----------
I hope this helps some. We are still woefully short of documentation in this area and much about "siblings" is not particularly obvious. (But I presume that people interested in "siblings" will have read the contents of the "All Scripts" help-flap that is obtained by clicking on the ? in the all-scripts tool.)
A couple of nice, simple tutorial projects in Squeak about these matters would be so very welcome...
Cheers,
-- Scott
Hi Scott,
Thanks for the explanation. I'm going to see if I can make the tutorials you suggest. I agree they would be helpful .....
AFAIK, it's fine to have an all-scripts tool open as you create, delete, rename, and otherwise manipulate objects and scripts; I'm not aware of situations where it "misses" anything, but if you can describe a sequence of steps leading to such a situation, it would be helpful.
I'll report further on this. I have a feeling that what you've explained is the answer (and that's all material that should be presented simply in a tutorial style).
(But I presume that people interested in "siblings" will have read the contents of the "All Scripts" help-flap that is obtained by clicking on the ? in the all-scripts tool.)
I missed this but have read it now and it's really helpful and perhaps also a roadmap of sorts for the simple tutorials ....
Thanks again,
Mark
Scott Wallace wrote:
On Apr 13, 2008, at 8:20 AM, polishookm wrote:
To answer my own question, I think what I'm observing is noted below. If someone could comment that what I'm describing is how things work, that would be great.
Hi, Mark,
Basically, your observations are correct, but please see the comments after #9 and #10.
- I make an EllipseMorph
- I open a viewer on the EllipseMorph and make a script. The script
belongs to a Player and the Player wears the EllipseMorph 3. I bring up a halo on the EllipseMorph and click on the green Duplicate icon. 4. Now I have 2 Players, each of which wears an EllipseMorph 5. Opening an AllScriptsTool provides for start/stop/stop control over both Players
- I make a RectangleMorph
- I open a viewer on the RectangleMorph and make a script. The script
belongs to a Player and the Player wears the EllipseMorph 8. I bring up a halo on the RectangleMorph and shift-click on the green Duplicate icon. 9. Now I have 1 Player that's wearing (controlling) 2 RectangleMorphs.
Almost... What you now have are two *sibling players*, each of which is a "Player" in its own right. Each players wears its own separate RectangleMorph as its costume. The siblings are related in that they have (and will forever have) the same "shape" (i.e. each has the same list of "variables") and in that they share (and will forever share) the same scripts. If you add a variable to one of them, the same variable will be added to the other. If you add a script to one of them, the same script will apply to the other one.
But although siblings share a script, each sibling has its own private "status" for that script, i.e. remembers separately whether the script *as used by this instance* is "normal", "paused,", or "ticking", or set to trigger on mouse-up, etc.; and what the tick-rate is.
When using siblings, what's really happening underneath is that there is a custom Player "Class" is created to bear the shared code, and the siblings are individual "Instances" of that class. "Class" and "Instance" are among the most fundamental concepts of object-oriented programming, but we don't much use the terms "class" and "instance" in the etoys UI, nor in any documentation I'm aware of. (A notorious exception is the "all instances" checkbox in the all-scripts tool.) We refer to "siblings" but don't have a formal term for the "class". Hmm... maybe the checkbox should read "all siblings" rather than "all instances"...
- Opening an AllScriptsTool provides for start/stop/stop control
over the Player that wears the 2 RectangleMorphs
If the "all instances" box is not checked, you'll see the scripts for only one player of each sibling group. This will give you "control" over the scripts of only one of the players. If you want to be able to "control" scripts for both of the siblings, make sure the "all instances" checkbox is checked.
I'm noticing that if AllScripts tool is on screen while EllipseMorphs or RectangleMorphs are being duplicated, it won't then immediately pick up on the fact that new Players exist. A new Player has to be run once and then the AllScriptsTool knows it's there.
Unless the "all instances" checkbox is checked, creation of new siblings will typically not result in any noticeable change in the all- scripts tool, since all the scripts of the new sibling will already be represented by another instance in the tool. Perhaps that's what you're seeing.
Also, if the "tickers only" box is checked, only scripts whose status is "ticking" or "paused' are shown in the all-scripts tool. This can be another reason why the all-scripts tool may seem not to be "picking up" on a change.
AFAIK, it's fine to have an all-scripts tool open as you create, delete, rename, and otherwise manipulate objects and scripts; I'm not aware of situations where it "misses" anything, but if you can describe a sequence of steps leading to such a situation, it would be helpful.
I hope this helps some. We are still woefully short of documentation in this area and much about "siblings" is not particularly obvious. (But I presume that people interested in "siblings" will have read the contents of the "All Scripts" help-flap that is obtained by clicking on the ? in the all-scripts tool.)
A couple of nice, simple tutorial projects in Squeak about these matters would be so very welcome...
Cheers,
-- Scott _______________________________________________ Etoys mailing list Etoys@lists.laptop.org http://lists.laptop.org/listinfo/etoys
On Monday 14 Apr 2008 2:47:12 am Scott Wallace wrote:
When using siblings, what's really happening underneath is that there is a custom Player "Class" is created to bear the shared code, and the siblings are individual "Instances" of that class. "Class" and "Instance" are among the most fundamental concepts of object-oriented programming, but we don't much use the terms "class" and "instance" in the etoys UI, nor in any documentation I'm aware of.
The viewer category "an Object" contains a class tile. An EToy is initially in "UnscriptedPlayer" class. When the first script is created, the class gets reassigned to a unique Player<n> value. This value stays even if all the scripts in the Player are deleted. Should it revert to UnscriptedPlayer in this case?
(A notorious exception is the "all instances" checkbox in the all-scripts tool.) We refer to "siblings" but don't have a formal term for the "class". Hmm... maybe the checkbox should read "all siblings" rather than "all instances"...
and also in the "make a sibling instance ..." in the siblings menu item of red halo button.
The copy tile in miscellaneous category uses the term "clone" for sibling.
This mixing of metaphors (drama, family, genetics) is confuses children. So, I use the analogy of chorus dancers to explain this part of EToys. Each dancer in the group may wear a different costume, have different heights or locations on stage, but they all perform to the same script. One eight-year applied the concept to animate falling snow for a winter scene.
Subbu
etoys-dev@lists.squeakfoundation.org
-
Bert Freudenberg -
K. K. Subramaniam -
Kazuhiro ABE -
polishookm -
Scott Wallace