Daniel,

> 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'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, set the trigger to
"mouse down", grab a second "color <- <...>" tile, change it to "mouse up"
and 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).

And this is exactly what I said in my message (and what frustrates me so
about what you write) - if anything we need *MORE* eToy-like things in
Squeak and and in particular at the system level. What you are proposing is
not just one, it's two steps backwards.

Cheers,
  - Andreas