Andreas Raab <andreas.raab at gmx.de> wrote:
> > as a
> > user of windowing systems, I usually assume the mouse even will be
> > handled by precisely whatever is under it...
> Only upon mouse down events and only if there are no modal dialogs/windows.
> In all other cases the mouse input will go somewhere else. This is true for
> all systems I know about.
Ah, right. Ok.
 
> > > When an event is dispatched it uses (sometimes varying) 
> > > strategies to figure
> > > out where it ends up.
> > It's not very clear here who might participate in distributing the
> > event. Pointers?
> 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?

> > I'm not quite clear what you mean here - what's a front-most chain?
> > start from front most, then go up the owner chain?
> At each morph in the hierarchy there is one (or none) morph which is
> front-most under the mouse (or more accurately: at the point where the event
> 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?" 

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?

Daniel Vainsencher