[Squeakland] "add a parameter" script feature in etoys

Scott Wallace scott.wallace at squeakland.org
Tue Nov 6 18:36:19 PST 2007

Hi, Bill,

Sorry for the confusion... the example is for use in an olpc etoys  
image -- see http://wiki.laptop.org/go/Etoys.

As we announced last summer, our intention is to shift Squeakland  
users over to an olpc-based image this year (a large amount of work  
has gone into improving etoys for the olpc) but we have been so  
preoccupied with meeting one olpc deadline after another that we  
haven't finished following through on that yet.


   -- Scott

On Nov 6, 2007, at 6:13 PM, Bill Kerr wrote:

> hi Scott,
> thanks for reply
> when I download your pr file I get this message:
> "Reading an instance of MorphExtensionPlus, which modern class  
> should it translate into"
> What should I do, I'd like to see your demo
> thanks,
> - Bill
> On Nov 7, 2007 11:55 AM, Scott Wallace  
> <scott.wallace at squeakland.org> wrote:
> On Nov 1, 2007, at 3:50 PM, Bill Kerr wrote:
> > I can't assign a variable to the "add a parameter" feature available
> > through the scripts menu in etoys. The parameter type is displayed
> > and the type can be altered but it doesn't go green when I try to
> > replace it with a variable of the right type. I can drag off a tile
> > for the parameter type but that doesn't seem to help.
> Hi, Bill,
> I'm not sure I understand exactly what you're asking, but perhaps a
> few general words about script parameters, and a simple example, will
> be helpful...
> The "Tile for the parameter type" that you can drag from the header of
> a Scriptor is actually a tile representing the parameter value
> itself.  You can drop such a tile at any type-appropriate place within
> the body of the script.  Thus, if the parameter type is "color", the
> tile will be labeled "Color", and can be dropped on any Color-type
> tile in the script, and if the parameter type is "number", the tile
> will be labeled "Number" and can be dropped on any Number-type tile in
> the script, etc.
> I attach a small example which illustrates use of a script parameter.
> The script that has a parameter is called "wobble", and it takes a
> numeric-valued parameter.  Its role is to make the object turn by a
> random amount within the limit specified by the parameter.  The larger
> the value of the parameter, the wider will be the variance.  Notice
> that in the body of the script, there are two places where a "Number"
> tile, representing the value of the numeric parameter, is used.  Both
> of these "Number" tiles were obtained by dragging them from the
> "number" tile in parameter area in the header, then dropping them on
> numeric-valued tiles:
> A typical use of such a script can be seen in the two other scripts in
> the example, one called "wideWobble", which calls "wobble" with a
> parameter value of 70 (degrees), which makes for fairly wild random
> wobble, and the other called "narrowWobble", which calls "wobble" with
> a parameter value of 20 degrees, which makes for much less erratic
> motion.
> Here's the script for "narrowWobble":
> You can experiment with the behavior of these two scripts by holding
> down the yellow "!" control for one or the other, or by first making
> one of them "ticking", then observing the effect, then stopping that
> script and making the other one tick, etc.  Or, for a combined effect
> (fwiw) make them both tick at the same time, perhaps at different
> ticking rates.
> BTW:  we have successfully prototyped a much better UI for presenting
> parameters to the user; the new design allows the user to *name* the
> parameter, allows a *default value* for the parameter to be specified
> in the scriptor's header, and (because of now having a default value)
> also allows a script with a paremeter to be set "ticking".   But
> unfortunately we haven't had time yet to bring this into the
> mainstream etoys system.
> > I'm trying to make a fractal tree in etoys but need two parameters.
> > Is it possible?
> No, sorry, only one parameter is allowed per script in this version of
> etoys.
> The standard workaround for this is to pass the desired additional
> parameter info in a *variable* which you add to the object for just
> this purpose, and which you set in the caller, and which you "get" in
> script itself.  This requires extra bookkeeping by the person writing
> the script, and can cause problems in recursive-call situations, but
> otherwise in practice is quite workable.  And, since the data being
> passed reside in visible variables belonging to the object, their
> values can be conveniently observed in Viewers and Watchers, which can
> be quite a good debugging aid.
> Cheers,
>   -- Scott

More information about the Squeakland mailing list