[DOCS] Morphic events (was: RE: Pink Plane vs Blue Plane)
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
So, IIUC, behavior here is specialized by overriding
#processEvent:using:, and by subclassing MorphicEventDispatcher. Did I
> > 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
More information about the Squeak-dev