Looking for good examples of morph programming
ned at bike-nomad.com
Tue May 20 15:48:34 UTC 2003
On Tuesday 20 May 2003 12:47 am, Lex Spoon wrote:
> > > Why do it this way? I tend to lean the opposite direction.
> > > Using mouseDown: methods makes the code easier to browse.
> > reassign the event behavior
> [ ... ]
> > it handles the waitForClicksOrDrag: stuff
> [ ... ]
> > eToys
> Okay. I would have thought this kind of thing was handled in
> handleMouseDown: , but you're right. I don't know why
> handleMouseDown: *doesn't* do these things.
Because (I think) it's relatively high overhead to make a
MouseClickState object for every mouse click.
> There are 80 implementors of mouseDown: in my image. Are none of
> them supposed to be amenable to, say, having EToys override the
> mouseDown activity? That doesn't seem right, but it's the way it
Most of them are either widgets with very specialized needs (and that
are never "out there" alone in a World to be scripted), or they call
"super mouseDown:" somewhere.
Generally, the ones that should respond to #on:send:to: are the ones
that might be useful by themselves (as opposed to, say, a
There *are* some that don't play well (my Connectors come to mind here
-- cough, cough --) with eToys.
GPG key ID: BEEA7EFE
More information about the Squeak-dev