Dear Andreas,

> > we could use this kind of
> > refactoring to separate the "Morphic" programmers use to build boring
> > old applications, from the "Morphic" that's perfect for eToys.
> 
> Nothing personal, but as of now, this is the most frustating message I have
> seen in this thread. Don't you realize that the Morphic that is perfect for
> eToys *is* the one that is perfect for programmers?
> 

I'm game. Help me out.

> I'll give you just one example: If I want to make a button in eToys, here is
> what I do. I go to the supplies flap, grab a rectangle, open its viewer,
> drag out the "color <- <...>" tile, set the color I want,

Small problem: The damn thing is too small for me to set the color I
want with any accuracy. I have tried a few times to enlarge it so *I*
can use it, but without success.

> set the trigger to
> "mouse down", grab a second "color <- <...>" tile, change it to "mouse up"
> and done.
> 

That's a bit cryptic. I had to open 2 scripts to do that.
And, err, done? 

> If I want to make the same button using your "programmer's morphic" here is
> what I needed to do: Go to the tools flap, open a browser, make a category
> "My stuff" (never mind that I might have no idea where to go next after
> opening the browser), figure out the thing I have to subclass (nevermind
> that I might have never heard of Morph or RectangleMorph or whatever else),
> define my class. Then I need to know what exactly this method is called that
> I have to write - it's #mouseDown: (nevermind that I have no interest
> whatsoever in the event which is passed along), then I need to write
> something like:
>         self color: (Color r: 0.67 g: 0.43 b: 0.95).
> (nevermind that I have to know these numbers, nevermind that I have to know
> that I must not assign to the instance variable even though it happily
> allows me to), then I implement a similar method for mouseUp:, then I need
> to remember that this isn't enough - oh no, I still need #handlesMouseDown:
> (as if the system couldn't figure out for itself). Now I have a class where
> I have no idea whether it'll work or not. So then I open up a work space, go
> in there type "MyButtonMorph new openInWorld" (nevermind that I have to
> remember that weird message) and then I can finally see if I have made a
> mistake or not.
> 
> So which way would you rather use yourself?! Unless someone has a really
> masochistic inclination I can safely claim that the first one is the way to
> go - it's better in every single way, starting from the ability to use
> direct manipulation, over robustness, up to efficiency (even I need about
> five times as long with the second one and I know *exactly* what I'm doing).
> 

IMX so far, I had to do both. I was unable to program what I wanted with
the scripting language. Maybe I missed something. So I ended up going to
the trouble you indicate, as well. :-(

After reading your note, I thought I must have missed something, so I
went through Dan Shafer's tutorial again. I did miss something. I was
curious just how creating an instance variable for the text morph
created a number, just what was needed! A little fooling around revealed
that I could change the type of the instance variable. I had 9 choices.
Neat!

One problem. For what I wanted to do I needed a collection. Not there. 

OK, let's keep this fairly simple. You are a GoPointMorph. On mouse up,
you want to play a stone on yourself (add an EllipseMorph of the right
size, shape, and color), if it is legal to do so. Let's write a script
to find out. To do that, we have to communicate with the current go game
being played. But the game has to be a Morph, right? Otherwise, no tile
for it. Luckily, there is a GoGameMorph, which looks like a button. It
has an instance variable which is a history of the game so far,
including the current position. Let's add a stone on my point to the
current position and see if the resulting position is already in the
history. OK, let's open a viewer on the go game morph and get the tile
for the game history. 

No can do, right?

Well, maybe I can send a message to the go game. We can get its tile.
Let's add it to the script. Oops. No puedo,sennor.

Believe me, the first time around I did not even get this far, although
it took me longer.

The scripting language is fine, but it seems too limited for what I am
interested in. Maybe I am still missing something.

But you see what I meant earlier by asking for better communication
skills for Morphs. And for help creating subclasses from Morphs.

Thanks,

Bill