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

Milan Zimmermann milan.zimmermann at sympatico.ca
Mon Nov 20 22:22:45 PST 2006


On 2006 November 14 10:41, Alan Kay wrote:
> Hi Offray --
...
> 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.
>

Hi Alan,

I could not resist - is this planned to be a new version eToys, or more of an 
extension, and, is it planned to be of the current OLPC/Squeakland Morphic 
based lineage or rather the Tweak eToys lineage? Or perhaps it's not defined 
yet,

Thanks Milan

> 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
>
> _______________________________________________
> Squeakland mailing list
> Squeakland at squeakland.org
> http://squeakland.org/mailman/listinfo/squeakland


More information about the Squeakland mailing list