Hi,
There are projects like snake eating stars for which sibling is the best solution and other for instance making traffic light, for which duplicate is necessary.
Just take an ellipse and make a script on giving a bright red color to the ellipse and off giving a dark red.
To get the yellow light, make a copy. Now you just have to change the red color by the yellow one in the two scripts.
The kids are very surprised that now their onld red light is magically turned to a yellow one if the copy is a sibling one.
For me the best solution is to have by default a duplicate halo and by clicking with the shift key down to get a sibling.
For kids or common user, it seems to me that the idea that a copied object is doing the same things that the original one because the scripts are copied too and are the same.
This inducing the idea to get a copy and just change the color in the scripts, this is only working with duplicate.
For a programmer making an instance is more economic, specialy if we have to make a lot of instances.
All that to say we need both. We need an easy way to make our choice and we have to choose the most intuitive one as default.
Parts bin are making duplicate.
But the Make button for connectors is making sibling.
Saying this, I just get the idea that objects get a check box saying if they have to be copied as duplicate or as sibling.
This way part bin will be able to create either sibling or duplicate depending of the future use of the object.
This will be coherent with the actual behavior, just the check box will change when the object is getting a script.
And last but not least the duplicate as default beeing a preference of E-toy friendly.
Best regards
-----Message d'origine----- De: squeakland-bounces@squeakland.org A: stéphane ducasse; Scott Wallace Cc: squeakland@squeakland.org Date: 27.12.04 17:25 Objet: Re: [Squeakland] Where can I find a description of make siblings
Hi Folks --
Actually, this is all being thought through once again as we try to design and build the "Omniuser Authoring System" of which the next version of the kids' etoys system should be a subset.
I think that copy actions are too cavalier on the one hand, and classes are too top down and rigid on the other. We need something in between these two extremes. E.g. I would like to be able to "promote" an example player to
being a "source" for instances. I think this will call for several UI changes, including ways to mark and find the "sources".
Ideas?
Cheers,
Alan
At 06:34 AM 12/26/2004, stéphane ducasse wrote:
Hi scott
I digested quite well your explanation (in fact this was what I
thought).
I was always thinking that halo actions would not contain copy *and*
make
a sibling.
The change made in 3.8 is that once an object has been *scripted*, the
halo handle seen at the top-right of its halo will now be an olive colored handle whose operation makes a sibling-instance rather than a deep-copy.
and in addition this is what confused me. I was looking anymore at halo
actions since I thought that I would get all the time the make-sibling (and not copy). What pierre-andre was suggesting was to have
make-sibling
per default and with with plus green halo copy. this way you do not have to go into the halo menu mess.
Stef
Squeakland mailing list Squeakland@squeakland.org http://squeakland.org/mailman/listinfo/squeakland
_______________________________________________ Squeakland mailing list Squeakland@squeakland.org http://squeakland.org/mailman/listinfo/squeakland
Hi, all.
An update is now in the works that will offer the following improvements, prompted primarily by the very valuable observations and suggestions from Pierre-André and Stéphane.
(1) Shift click on a copy handle now results in "the other kind of copy". Thus, shift-click on the bright green "deep-copy" halo handle now tears off a "sibling instance" instead. And shift-click on an olive "make-sibling" handle now tears off a "deep copy." Balloon-help for the halo handles mentions both alternatives. Thus, both kinds of "copy" are always directly available from the halo without any fishing in menus and submenus.
(2) Which of the two possible "copy" handles to show in the halo of a scripted object is now governed by a new "preference," oliveHandleForScriptedObjects; this can be set to give either the "traditional" behavior, in which the bright green handle is the only one ever actually shown, or the recent alternative in which the olive "sibling" handle is shown on scripted objects.
(3) When a user sets the "eToyFriendly" preference to true, as per Pierre-André's suggestion, the oliveHandleForScriptedObjects preference is automatically set to false, so that the bright-green "deep copy" will always be the one shown, as in past years, unless you proactively flip oliveHandleForScriptedObjects back to true.
(4) In the "siblings" branch of the halo menu, a new item, "indicate all siblings," appears. Choose this to highlight momentarily the object and all of its siblings, all at the same time. This gives you a direct way to find out which objects are siblings of each other.
(5) Lastly, any individual object can now express an individual preference for which kind of "copy" handle should be shown at the top-right of its halo.
Any other experiences that anyone has to report on kids' use of multiple sibling instances, etc., would be very interesting to hear.
Cheers,
-- Scott
PS: Anyone familiar with "installing a fileout" is invited to install the attached into a copy of a Squeakland image to test-drive the changes described above. But commentary on this matter is solicited from everyone, test-driver or not.
At 5:37 PM +0100 12/29/04, Dreyfuss Pierre-André (EDU) wrote:
Hi,
There are projects like snake eating stars for which sibling is the best solution and other for instance making traffic light, for which duplicate is necessary.
Just take an ellipse and make a script on giving a bright red color to the ellipse and off giving a dark red.
To get the yellow light, make a copy. Now you just have to change the red color by the yellow one in the two scripts.
The kids are very surprised that now their onld red light is magically turned to a yellow one if the copy is a sibling one.
For me the best solution is to have by default a duplicate halo and by clicking with the shift key down to get a sibling.
For kids or common user, it seems to me that the idea that a copied object is doing the same things that the original one because the scripts are copied too and are the same.
This inducing the idea to get a copy and just change the color in the scripts, this is only working with duplicate.
For a programmer making an instance is more economic, specialy if we have to make a lot of instances.
All that to say we need both. We need an easy way to make our choice and we have to choose the most intuitive one as default.
Parts bin are making duplicate.
But the Make button for connectors is making sibling.
Saying this, I just get the idea that objects get a check box saying if they have to be copied as duplicate or as sibling.
This way part bin will be able to create either sibling or duplicate depending of the future use of the object.
This will be coherent with the actual behavior, just the check box will change when the object is getting a script.
And last but not least the duplicate as default beeing a preference of E-toy friendly.
Best regards
-----Message d'origine----- De: squeakland-bounces@squeakland.org A: stéphane ducasse; Scott Wallace Cc: squeakland@squeakland.org Date: 27.12.04 17:25 Objet: Re: [Squeakland] Where can I find a description of make siblings
Hi Folks --
Actually, this is all being thought through once again as we try to design and build the "Omniuser Authoring System" of which the next version of the kids' etoys system should be a subset.
I think that copy actions are too cavalier on the one hand, and classes are too top down and rigid on the other. We need something in between these two extremes. E.g. I would like to be able to "promote" an example player to
being a "source" for instances. I think this will call for several UI changes, including ways to mark and find the "sources".
Ideas?
Cheers,
Alan
At 06:34 AM 12/26/2004, stéphane ducasse wrote:
Hi scott
I digested quite well your explanation (in fact this was what I
thought).
I was always thinking that halo actions would not contain copy *and*
make
a sibling.
The change made in 3.8 is that once an object has been *scripted*, the
halo handle seen at the top-right of its halo will now be an olive colored handle whose operation makes a sibling-instance rather than a deep-copy.
and in addition this is what confused me. I was looking anymore at halo
actions since I thought that I would get all the time the make-sibling (and not copy). What pierre-andre was suggesting was to have
make-sibling
per default and with with plus green halo copy. this way you do not have to go into the halo menu mess.
Stef
Squeakland mailing list Squeakland@squeakland.org http://squeakland.org/mailman/listinfo/squeakland
Squeakland mailing list Squeakland@squeakland.org http://squeakland.org/mailman/listinfo/squeakland
Yoshiki found a bug in the fileout I sent last week (which manifested itself when one switched the eToyFriendly preference on and then back off;) I herewith attach a fixed version -- please use it instead of the version I sent on Monday.
Never did get any feedback from anyone about this, however :-(
Cheers,
-- Scott
At 3:58 AM -0800 1/3/05, Scott Wallace wrote:
Hi, all.
An update is now in the works that will offer the following improvements, prompted primarily by the very valuable observations and suggestions from Pierre-André and Stéphane.
(1) Shift click on a copy handle now results in "the other kind of copy". Thus, shift-click on the bright green "deep-copy" halo handle now tears off a "sibling instance" instead. And shift-click on an olive "make-sibling" handle now tears off a "deep copy." Balloon-help for the halo handles mentions both alternatives. Thus, both kinds of "copy" are always directly available from the halo without any fishing in menus and submenus.
(2) Which of the two possible "copy" handles to show in the halo of a scripted object is now governed by a new "preference," oliveHandleForScriptedObjects; this can be set to give either the "traditional" behavior, in which the bright green handle is the only one ever actually shown, or the recent alternative in which the olive "sibling" handle is shown on scripted objects.
(3) When a user sets the "eToyFriendly" preference to true, as per Pierre-André's suggestion, the oliveHandleForScriptedObjects preference is automatically set to false, so that the bright-green "deep copy" will always be the one shown, as in past years, unless you proactively flip oliveHandleForScriptedObjects back to true.
(4) In the "siblings" branch of the halo menu, a new item, "indicate all siblings," appears. Choose this to highlight momentarily the object and all of its siblings, all at the same time. This gives you a direct way to find out which objects are siblings of each other.
(5) Lastly, any individual object can now express an individual preference for which kind of "copy" handle should be shown at the top-right of its halo.
Any other experiences that anyone has to report on kids' use of multiple sibling instances, etc., would be very interesting to hear.
Cheers,
-- Scott
PS: Anyone familiar with "installing a fileout" is invited to install the attached into a copy of a Squeakland image to test-drive the changes described above. But commentary on this matter is solicited from everyone, test-driver or not.
At 5:37 PM +0100 12/29/04, Dreyfuss Pierre-André (EDU) wrote:
Hi,
There are projects like snake eating stars for which sibling is the best solution and other for instance making traffic light, for which duplicate is necessary.
Just take an ellipse and make a script on giving a bright red color to the ellipse and off giving a dark red.
To get the yellow light, make a copy. Now you just have to change the red color by the yellow one in the two scripts.
The kids are very surprised that now their onld red light is magically turned to a yellow one if the copy is a sibling one.
For me the best solution is to have by default a duplicate halo and by clicking with the shift key down to get a sibling.
For kids or common user, it seems to me that the idea that a copied object is doing the same things that the original one because the scripts are copied too and are the same.
This inducing the idea to get a copy and just change the color in the scripts, this is only working with duplicate.
For a programmer making an instance is more economic, specialy if we have to make a lot of instances.
All that to say we need both. We need an easy way to make our choice and we have to choose the most intuitive one as default.
Parts bin are making duplicate.
But the Make button for connectors is making sibling.
Saying this, I just get the idea that objects get a check box saying if they have to be copied as duplicate or as sibling.
This way part bin will be able to create either sibling or duplicate depending of the future use of the object.
This will be coherent with the actual behavior, just the check box will change when the object is getting a script.
And last but not least the duplicate as default beeing a preference of E-toy friendly.
Best regards
-----Message d'origine----- De: squeakland-bounces@squeakland.org A: stéphane ducasse; Scott Wallace Cc: squeakland@squeakland.org Date: 27.12.04 17:25 Objet: Re: [Squeakland] Where can I find a description of make siblings
Hi Folks --
Actually, this is all being thought through once again as we try to design and build the "Omniuser Authoring System" of which the next version of the kids' etoys system should be a subset.
I think that copy actions are too cavalier on the one hand, and classes are too top down and rigid on the other. We need something in between these two extremes. E.g. I would like to be able to "promote" an example player to
being a "source" for instances. I think this will call for several UI changes, including ways to mark and find the "sources".
Ideas?
Cheers,
Alan
At 06:34 AM 12/26/2004, stéphane ducasse wrote:
Hi scott
I digested quite well your explanation (in fact this was what I
thought).
I was always thinking that halo actions would not contain copy *and*
make
a sibling.
The change made in 3.8 is that once an object has been *scripted*, the
halo handle seen at the top-right of its halo will now be an olive colored handle whose operation makes a sibling-instance rather than a deep-copy.
and in addition this is what confused me. I was looking anymore at halo
actions since I thought that I would get all the time the make-sibling (and not copy). What pierre-andre was suggesting was to have
make-sibling
per default and with with plus green halo copy. this way you do not have to go into the halo menu mess.
Stef
Squeakland mailing list Squeakland@squeakland.org http://squeakland.org/mailman/listinfo/squeakland
Squeakland mailing list Squeakland@squeakland.org http://squeakland.org/mailman/listinfo/squeakland
Attachment converted: titanium:sibHalo-sw.cs.gz (SOBJ/FAST) (0013286F)
squeakland@lists.squeakfoundation.org
-
Dreyfuss Pierre-André (EDU) -
Scott Wallace