Scripting Problems & Wishes

Scott Wallace Scott.Wallace at disney.com
Thu Oct 14 05:34:12 UTC 1999


Hi, David, and thanks for your thoughtful observations.

At 3:43 PM -0400 10/13/99, David N. Smith \(IBM\) wrote:

> I've been 'playing' with scripting, and having a lot of fun, and have
> run into some problems or 'features', or have tried to do things that
> I can't appear to do. I know it's all new, that I don't know it very
> well yet, and that 2.6 may have changed it all; I'm still on 2.5
> (with all updates applied). Anyhow, I hope no one minds if I mention
> a few things I've run into.

Generally, the problems and "features" you mention are indeed problems and (mis)features.  Bless you -- brave soul! -- for venturing into these waters without a reliable compass.

The scripting capabilities at present comprise more a demo and a sketch of a concept rather than a genuinely usable system.  They have allowed us to explore a space we wish to learn about, with this particular tile-based and event-driven and scripting-tangible-objects slant, and they have afforded quite a few intriguing demos, but the bounds of functionality have largely been defined by what was needed for the particular demos we wanted to produce. and we've added features and fixed up deficiencies on a just-in-time basis when a particular demo exposed a need.   Thus, there are numerous deficiencies and ragged edges, a couple of which you've run into.


> * Highlighting button. 
> 
> I've built a highlighting button by taking a rectangle morph and
> adding scripts that change its color. One triggered on mouseDown
> changes it's color to the highlight color, and the other, triggered
> on mouseUp, changes it back. Works fine. I added some text, embedded
> it, and locked it down. The button still works fine. 
> 
> I then add a script for it to do something useful; in this case to
> turn a Car. If the turn script triggers off of something besides
> mouseDown or mouseUp then the button still highlights. But if I
> trigger off of mouseDown then it turns the car but forgets how to
> highlight itself. If I change the trigger of the turn script to
> something else, the button still won't highlight even though the
> scripts appear to have but one mouseDown again. 
> 
> To fix it I have to reselect mouseDown for the highlighting script. 
> 
> So, two problems here: 
> 
>    - There can be but one script on a morph for each mouse action. 
>    - The system forgets to reenable other scripts with the same mouse 
>      trigger when one changes.

Your observation here is 100% correct, and this reflects a basic weakness of the scripting system in its nascent skin.   Any number of "ticking" scripts can coexist in the same object and they will all tick along harmoniously and concurrently, but only the last script defined to be triggered upon each particular mouse gesture on a particular object will actually be triggered by that gesture on that object.  The implementation is directly one-to-one with Morphic's "eventHandlers".

Until this limitation is transcended in a subsequent release, the workaround is the same as you'd use in any other event-driven system:  If you want both script A and script B to be triggered on mouseDown, then create a third script, say script C, and have *it* triggered on mouseDown, and have its code invoke script A and then script B.  Tedious, but practical.


> * Duplicating the highlighting button 
> 
> Using the halo's duplicate operation, I made a copy of the
> highlighting button (which contains a reference to a Car morph;
> pressing the button turns the car). I was going to change it to turn
> the car the other direction. Result: 
> 
>    - The button is duplicated AND the car is duplicated. 
> 
> 
> There are two cars and I can run and turn each separately. I expected
> two buttons that turned the same car. The two car morphs have the
> same name, 'Car', but separate existence and separate viewers. 
> 
> Is this the proper action?


No -- this is clearly a bug in the duplication code.  There were several rapid cycles of rewriting of morphic's object-duplication code a few months back, and it sounds as if the current incarnation of "veryDeepCopy" copies a little too deeply.  What you were expecting is what *should* happen.  I'll pass this bug report on to our veryDeepCopy specialist.


> * Dragging 
> 
> I've tried to build a car with a steering wheel that I can drag
> around in a circle like one moves a real steering wheel. (The example
> discussed here in August was quite neat, but it requires that halo's
> be accessible, and in a packaged product they won't.) 
> 
>    - There is no way to specify a mouseDrag operation. 
> 
> I'd expect, I think, for it to trigger its script while dragging (say
> at each tick). The script could see the current position (and maybe a
> delta). For rotation (see below) it would see a change in orientation
> (and maybe a delta).

If you write a script and have it trigger on mouseStillDown, you can control the drag and the consequences.  In the mouseStillDown-triggered script, you can retrieve the current cursor point (use the mouseX and mouseY variables of its containing Playfield), and based on that, you can (for example) have the script change the heading of the object, thus rotating it.  This is strenuous but possible.


> * Rotation 
> 
> On several things I've wanted to try, I wanted a morph to have a
> center of rotation. On one, it would have to be external from the
> morph (as in a handle that rotates around a hidden shaft). It's true
> that one can rotate a morph, but only about its center. 
> 
>    - There is no way to specify a center of rotation.

You *can* specify a center of rotation for any SketchMorph -- look in the "painting..." branch of its halo menu.


> * Hitting the wall 
> 
> There seems to be no way to make a script that runs when a moving
> object hits the wall, though something clearly happens from all the
> noise it makes! :-) 

Actually there *is* -- though it's admittedly somewhat strenuous.  First of all, turn off the "fence enabled" preference, so you won't have the generic handling of boundary-hits getting in the way.  Then you can test, in a script, whether your object's "left" is less than its container's "left", and take appropriate action if it is.  Similarly for the other edges.

Looking ahead, we obviously need, and definitely will have, a formalism for collision detection -- viz, a way that scripts can be triggered when objects collide.  "Hitting the wall", though not strictly a morph-hit-morph situation, would fall under this umbrella.


> I've had various other problems but I can't duplicate them. Twice
> there has been a recursion that ran the VM out of memory, and it
> seemed to have something to do with scripting.

It's certainly as possible to create recursions in the Scripting world as it is in Squeak generally.  And there definitely are numerous loose ends.  We never really expected that our first take on tile-based scripting would still be alive in late 1999!  The time for a radical new take on this stuff is probably not too far off.

One other observation:  To help span the huge gap between the minuscule vocabulary of the tile-scripting regime and the full power of Squeak, remember that you can say "edit script textually" to any tile script, whereupon you can then proceed to write arbitrary Squeak code in it.  In such a script, "self" is the Player object; "self costume" is the affiliated morph.  You can get at the current hand and the current world via "self currentHand" and "self currentWorld", etc.  Of course, if one is going to fall back on vanilla Smalltalk then arguably one has gone outside the simplified and end-user-oriented domain of scripting.

On the other hand, we believe that in spite of the obvious limitations and difficulties of the current scripting experiment, there is much to be learned from it that we intend to factor back into full-power Squeak.  This is a matter of considerable importance to us.


Many thanks for your interest and your efforts.  I can promise you (and anyone else who may take an interest in this topic) that every observation you pass along is valuable and will be taken to heart, and that every communication you send regarding these matters will be carefully read and responded to.

  -- Scott





More information about the Squeak-dev mailing list