[DOCS] Morphic events (was: RE: Pink Plane vs Blue Plane)

Daniel Vainsencher danielv at netvision.net.il
Fri Feb 14 15:55:31 UTC 2003

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

More information about the Squeak-dev mailing list