On Sep 22, 2007, at 6:54 , Derek O'Connell wrote:

Thanks Matthew. I don't know the "correct" way to implement new etoys and as you have probably discovered there is little if any documentation for potential developers. This is a shame as I'm sure there would be a lot more of them by now (fully scriptable ones that is). According to others etoys is a demo that wouldn't die,

That's just Alan's own tongue-in-cheek characterization, he's always striving for a better thing.

which maybe explains why no one seems to be going out of their way to support/promote their development. Which leaves me, at least, a little confused since etoys appear to be a well cited "feature" of the OLPC software.

Well, despite of it being intended as a short-lived experiment, it became quite feature-rich and even robust over the last 10 years. It is useful to a world-wide user community already and will certainly be one of the deeper activities available for the XO environment.

Given the limited man-power in our group and OLPC's schedule we had no option but to revive Etoys once more, give it a face lifting and a few prostheses to fit into the Sugar environment and here we are. There is, most unfortunately, no serious alternative. Except for the next thing we're working on, but that will take a few more years. We needed something now.

Just glancing through etoy related classes leaves me a bit stunned at the moment :-)

Oh, most of Morphic is etoys-related, the "etoys" class category is just the tip of the iceberg. So I can feel with you ;)

- Bert -

On Sep 22, 2007, at 5:09 , Matthew Fulmer wrote:

I was trying a custom morph/etoy and I wanted to make some of its instance variables (minAngle, maxAngle) accessible from the Viewer. I couldn't find any way to do this other than by adding four accessor methods to class Player. It seems this should only involve class modifications, but I don't see a way to make that happen. I did this in 3.10.

Is there a better way to do this that I am missing, or is Player really that ugly?

One of the core ideas of Etoys was to have only a single "rich" object type, not a hierarchy of classes. The embodiment of that idea is class Player.

By current standards, that design is indeed "ugly". But we're stuck with it at least for this generation of Etoys. The Tweak version of Etoys solved that problem.

It helps if you think of the *player* as primary scripted object. You are not scripting a Morph, it is only the costume for a Player, and can therefore be exchanged.

- Bert -