Daniel,

> > Like I was saying, see #dispatchEvent:. It delegates the task to
> > MorphicEventDispatcher.
> So, IIUC, behavior here is specialized by overriding
> #processEvent:using:, and by subclassing MorphicEventDispatcher. Did I
> miss anything?

Behavior can always be specialized by subclassing and re-implementing
certain messages. I don't get the question.

> > occured) forming a "chain" of front-most morphs.
> I now see that you this in the traveral down the tree, not up. But I
> still didn't get this. Do you mean "at each morph, there's 0-1
> *sub*morphs frontmost under the mouse?"

Obviously that's the case isn't it?! ;-) If I have a morph with a bunch of
submorph then for any given point on the screen there is exactly one or none
submorph which is front-most (as defined by #containsEvent:/containsPoint:)
at this point.

> Looking at MorphicEventDispatcher>>dispatchMouseDown:with:, I see -
> 	globalPt _ anEvent cursorPoint.
> 	(aMorph fullBounds containsPoint: globalPt) 
> ifFalse:[^#rejected].
> Which seems to conflict with what you said about morphs getting to
> handle events even if they're outside their owners bounds... how does
> this work?

I don't have the time to go into *that* level of detail right now. Most of
this is in order to a) not to have to establish the front-most chain of
morphs explicitly, b) be efficent and avoid exponential traversals of the
morph chain, and c) allow for "delayed rejections" of some event (IOW, if
some system- or user-level handler wants to appear "transparent" -not being
part of the front-most chain- it can do so). The actual implementation uses
both, the way down and the way up to determine which morphs are part of the
front-most chain.

Cheers,
  - Andreas