Marcus Denker wrote:

Another interesting question we got on the list (by a very motivated teacher): How to extend eToys. The teacher would like to build an eToy based environment for teaching math to older kids, and he would like to provide some pre-defined tiles.

I think this view of eToys as a framework for building curriculums is quite interesting, but there is no documentation about how to do "etoy" Metaprogramming...

Something similar to this question was discussed at the SqueakFest 2004, when there was a show of hands of how many attendees would be interested in such a thing: being able to create new tiles. Few people raised their hands (me included and I think Randy Heiland) but I do not know if that was converted into an action item. I was (and still am) very keen on knowing when such a possibility opens up.

 Marcus

-- Shashank

On Tuesday 21 December 2004 2:12 am, Marcus Denker wrote:

On the german list the question came up about etoys and keyboard support.

Is it possible to e.g. control the car with the keyboard?

Interesting you ask that. I made a project that shows just that. You can get it at:

http://bike-nomad.com/squeak/DriveUsingKeyboard.002.pr

but be sure you have the keystroke fix loaded first. This is in the Squeakland update stream (just "get updates"), but you can also get it at:

http://squeakalpha.org/updates/0377enableKeystrokeEvent-nk.cs

I searched the list, and in 2002 Karl Ramberg posted an enhancement (etoy keystroke.5.cs).

Has this (or something similar) been added to etoys in the meantime?

Yes. I have added simple (keystroke based) support for keys to the current Squeakland image, and have posted a fix CS to the Squeak-dev list that makes the (existing) support work with the current version work with Squeak 3.8.

Here is an excerpt from a message that I posted to the Squeakland list on 13 December (I also posted a similar one to Squeak-dev on the 14th).

-- There are two parts:

* The World has a String-valued property called 'lastKeystroke'. This is a string that holds the keystroke, in a form that can be used in string comparisons, like:

'a' '<left>' '<Ctrl-left>'

So you can have a ticking script (for instance) testing the lastKeystroke property. But you may very well miss one, unless you use the other part:

* You can trigger a script that is owned by the World on a 'keyStroke' event. You do this by clicking on the 'when this script should run' button, and choosing 'more' and then 'keyStroke'. --

Since that time I posted the fix I mentioned.

Note that this does *not* do keyUp/keyDown events, just keystrokes. So if you want to, say, have the rocket thrusting while a key is down, that's not currently supported.

What I had intended to do is to provide a KeyMorph and perhaps also a KeyboardMorph that could provide this kind of support. The keystroke support that I added recently is much more modest, and doesn't suffer from the problems of different keyboard maps.

The problem is that the keyDown/keyUp events are not associated with any meaning when they come in. So depending on what keyboard you have, several different physical keys (and hence keycodes) may generate, say, the "1" keystroke. And this will differ by physical keyboard, operating system, etc.

When we get a keyUp event, we also ask the operating system how to interpret that key code number as a keystroke. But until that time we just know the number.

I couldn't think of an easy way to deal with this problem in a cross-platform way, and I didn't want to make it so that people could make projects that couldn't easily be shared between different computers.

I am open to suggestions as to how to fix this. One idea I had was to learn the relationship: upon loading a project that uses particular keys, the KeyMorphs wouldn't know what numeric keycodes they needed to respond to. But they would know the keyStroke (like <left>). By watching *all* the keyUp/keyDown/keyStroke events (assuming the user is just pressing one key at once, and there are no combining or modifier keys also being used), we can see the correspondence between the keyUp events and the keyStroke events that follow.

Perhaps the KeyMorphs, upon being loaded or created, would prompt the user to press the given key so they could learn. Perhaps they could just not respond until the second press of their given key.

As I noted above, this is complicated by:

* modifier keys * combining keys and key sequences * sticky key states (Shift-Lock, Caps-Lock, Num-Lock, etc.) * chording: pressing multiple non-modifier keys at once * international input methods that may compress a long sequence of keys into one keystroke

Another interesting question we got on the list (by a very motivated teacher): How to extend eToys. The teacher would like to build an eToy based environment for teaching math to older kids, and he would like to provide some pre-defined tiles.

It is easy to add vocabulary items to Morph classes, and probably not as easy to extend (say) Number operations. For instance, I don't know how you'd add unary Number operators like sin and cos.

I think this view of eToys as a framework for building curriculums is quite interesting, but there is no documentation about how to do "etoy" Metaprogramming...

From a recent message that I wrote to the Squeak-dev list:

To extend the vocabulary of a Morph, you can just add methods named like additionsToVocabularyCategory* to the class side (look for such methods to get an idea). For each item, you typically need a method in Player and the corresponding method(s) in your Morph class.

For example, here is Morph class >> additionsToViewerCategoryLayout  "Answer viewer additions for the 'layout' category"

^#(   layout   (    (slot clipSubmorphs 'Whether or not to clip my submorphs' Boolean readWrite Player getClipSubmorphs Player setClipSubmorphs:)

))

So this adds the 'clipSubmorphs' slot to the 'layout' vocabulary category. That slot (a pseudo-variable) is read/write, and is implemented by the methods #getClipSubmorphs and #setClipSubmorphs on Player. Those methods just call back to the morph that is the Player's costume:

Player>>getClipSubmorphs  "Getter for costume's clipSubmorphs"  ^ costume renderedMorph clipSubmorphs

The other kind of thing you can add (besides the pseudo-variable 'slot' type) is the 'command' type, as in:

additionsToViewerCategoryMiscellaneous  "Answer viewer additions for the 'miscellaneous' category"  ^#(   miscellaneous   (    (command doMenuItem: 'do the menu item' Menu)    (command show 'make the object visible')

These don't have an associated return value, but they can have a single typed parameter.

I don't know where the best place for this kind of documentation would be. Do we have a Squeakland Swiki set up, or would the Squeak Swiki be the best place for this?