[Squeakland] Making a Copy of an eToy from a script and using the mouse pointer to activate an eToy script

[Alan Kay]

Hi Offray --

Etoys was designed for 9-11 year olds, and it has 
worked very well with them. However, even 8th 
graders are able to use more features, and high 
schoolers should be using a pretty complete 
programming environment (like Squeak).

You are not the only one to want to do more with 
Etoys, and I think this is because the basic 
notion of Etoys' universal objects, easy 
scripting and multitasking are things every 
programming environment needs. In "a year or so" 
we will have something more like a full spectrum 
system that can be used by a much wider range of users.

Squeak itself is very easy -- as Tony Hoare once 
said about Algol, Smalltalk was a great 
improvement, especially with its successors! -- 
the problem for beginners is that the library has 
only one organization, which kind of lumps 
everything together, and this is a large lump. 
This is powerful but can be quite frustrating 
(other comprehensive systems have similar 
problems). Etoys is kind of a demo that quite a 
bit can be done with much much less in the 
end-user's world, but the aim at 10 year olds 
limits its range. Our original plan was to wind 
up with a more Hypercard-like system, still small 
and simple, but much more comprehensive.

But, since Squeak is "live" and includes all of 
its parts and tools written in itself, much can 
be done with the existing system. For example, it 
is quite possible to make up an end user view of 
a system by making a special code browser for it 
that would only show the relevant useful classes. 
Morphic itself was designed to be quite simple 
and to allow quick naive presentations driven by 
Squeak methods. Etc. E.g. instead of trying to 
make the tile scripting system do things it 
wasn't designed to do, you might look at how 
morphs and players could be programmed in the Squeak code browser, etc.

This would produce a system with a simple and 
easy to learn syntax, huge expressive power, and 
a number of useful graphics classes to do things 
with on the screen. Not the very best thing that 
could be done for high schoolers, but would still 
allow a lot to be learned without huge expeditions into the library.

Cheers,

Alan

At 04:52 AM 11/14/2006, Scott Wallace wrote:
>On Nov 13, 2006, at 10:18 AM, Offray Vladimir Luna Cárdenas wrote:
>
>>Hi Scott :),
>>
>>Thanks for your help again. What you're providing me is pretty
>>close to what me and my students are looking for. Because my lack
>>of knowledge of the Smalltalk code I'm trying to understand the
>>textual script. I see that in that script, there is not switch from
>>tile mode to code/text mode, only the last one is enabled. There is
>>some special way to add this scripts? If I try, for example to use
>>the visor of a Star I always can switch from tile to code modes,
>>but coming back to tile, always makes the changes in text mode to
>>get loosed  (not saved).
>
>
>Hi, Offray!
>
>Once you have typed in textual code for a script, you cannot return
>to tile mode without losing the textual code you typed.  There is no
>automatic translation from user-entered textual code back into etoy
>tiles.  Indeed, the constructs supported by etoy tiles represent but
>a tiny fraction of what can be expressed in textual Smalltalk code.
>
>Some people are quite disappointed, and even offended, when they
>first learn this brutal fact.  But "etoys" is a tile-scripting
>system, with severe and intentional limits to vocabulary, sentence
>structure, expression structure, and control 
>structures.  The textual- scripting alternative 
>provides nothing more than a "keyhole" which
>allows some people to "escape" from tiles, into textual Smalltalk
>programming, specifically to program things that cannot be expressed
>with tiles.
>
>Because reverting from a textually-entered script back to tiles is
>destructive, the user is presented with a warning if he tries to do
>it -- a stern warning that any code he has manually entered via the
>keyboard for this script will be lost.
>
>The reason why this warning was not presented when you tried to click
>the text/tiles checkbox of the #chooseMessageTarget script to revert
>to tiles is because of a bug that appears when you attempt to toggle
>a textually-coded script which has never had any non-empty tile
>code.  (I have a fix for that bug, which I'm about to publish to the
>Squeakland alpha update stream.)
>
>However, even if had been allowed, you would not have wanted to
>revert that script to its last-known tile form, because in so doing
>you would have lost the textual code which is the whole point of the
>script.
>
>
>>chooseMessageTarget "the name of the script"
>>
>>  "Choose a player as target for a message" "<- comment with the
>>explanation"
>>  | aMorph | "<- some kind of local variable"
>>  aMorph := self costume chooseClickTarget. "<- this part changes
>>the mouse pointer of the world from arrow to cross-hair"
>>
>>"The following part gives a message to self to set message target,
>>if a not nil morph is chosen then the selected morph is assigned to
>>aMorph variable, if is Nil, I'm not pretty sure what's happening"
>>
>>    self setMessageTarget: (aMorph
>>        ifNil: [ActiveWorld presenter standardPlayer]
>>        ifNotNil: [aMorph assuredPlayer])
>>
>>-----
>>
>>I'm seeing that the world is "holding its breath" until a morph is
>>chosen, and everything stops for a while until the target of the
>>message has been choose. I image that this is related with the code
>>"ifNil: [ActiveWorld presenter standardPlayer] ...". There is a way
>>to keep the objects in the world moving, even with the message
>>target still to be selected?
>
>Actually, it's the "chooseClickTarget" which does all the work, and
>which causes the system to "hold its breath".
>
>This breath-holding is not absolutely necessary, it's just that
>that's how the underlying support for morph-picking has always worked
>in Squeak -- i.e. totally modally.
>
>To explore the possibility of relaxing this limitation, I've made a
>suggested fix and included it in the attached revised version #5 of
>the StarLemmings project; in this version, things will continue to
>breathe during target selection.  Please try it out and let me know
>what you think.
>
>
>Cheers,
>
>  -- Scott
>
>PS:  Just as an aside, I think that perhaps better than trying to
>learn Smalltalk by puzzling over little oddball textual snippets such
>as the one I provided for this project would be to download some of
>the great and free Smalltalk books (including a nice one in Spanish
>by Diego) from Stephane Ducasse's wonderful web site, which you
>probably already know about:
>
>http://www.iam.unibe.ch/~ducasse/FreeBooks.html
>
>
>
>ATTACHED:  StarLemmings.5.pr, revised version of the StarLemmings
>project which allows breathing during morph-picking.
>
>
>
>
>
>Content-Id: <96EF1165-24D5-4726-9589-310502925AD6 at local>
>Content-Type: application/octet-stream; x-mac-type=534F424A; x-unix-mode=0644;
>         x-mac-creator=46415354; name=Star Lemmings.005.pr
>Content-Disposition: attachment;
>         filename="Star Lemmings.005.pr"
>
>
>
>
>_______________________________________________
>Squeakland mailing list
>Squeakland at squeakland.org
>http://squeakland.org/mailman/listinfo/squeakland