Thanks for the description.  I've spent a fair amount of time looking
at the code, and this makes it much clearer.  Although it is conceptually
simple, trying to grasp it from the code without knowing the big picture
is not simple at all.

Joshua


On Thu, Feb 13, 2003 at 04:14:04AM +0100, Andreas Raab wrote:
> > The base event system in Squeak seems simple enough. Yet 
> > between morphic and handmorph, and all the others, it makes
> > my head hurt just trying to figure how Morphic utilizes raw
> > events to actually do something... >.<
> 
> Simple. HandMorph obtains MorphicEvents by either converting primitive input
> (from Sensor) or some other means (like remote connections). It then passes
> the event (depending on type) to any of the registered listeners (using
> #handleListenEvent:), and afterwards (again, depending on the type of the
> event) to its current focus (using #handleFocusEvent:). If there is no
> current event focus, it passes the event to its world, for further
> dispatching (using #dispatchEvent:).
> 
> When an event is dispatched it uses (sometimes varying) strategies to figure
> out where it ends up. The general rule of thumb is: The front-most, visible,
> unlocked chain of morphs "containg" the event (as determined by
> #containsEvent:) is travelled all the way down to a leaf morph. On its way
> up, each morph in the front-most chain of morphs is passed the event through
> #handleEvent:. BTW, this mechanism also ensures that even morphs where a
> child is outside of the parent can handle the event when it occured on some
> (out of bounds) child.
> 
> [One additional slant: When the hierarchy is traversed down, morphs may
> register itself as "being interested" in some event by establishing a
> prospective handler. This handler can be used to figure out which morph (if
> more than one is interested) should ultimately handle the event in question.
> This prospective handler is essentially a way of passing an extra argument
> into the event processing loop without having to know the exact construction
> hierarchy of the children].
> 
> When #handleEvent: is invoked, it double-dispatches the event into a
> system-level handler (such as #handleMouseDown:). The system-level handler
> typically checks whether the event was already handled, and if not, it marks
> the event as handled and dispatches to the user-level event handler (such as
> #mouseDown:).
> 
> Or, in short:
> * the hand generates a MouseDownEvent from Sensor's input
> * it sends the event using #handleListenEvent: to the registered listeners
> * it sends the event using #handleFocusEvent: to the current focus (if
> present)
>   [#handleFocusEvent: typically simply invokes #handleEvent:, see below]
> * if no focus, it sends the event using #dispatchEvent: to its owner (a
> world)
> * the event is dispatched along the front-most, visible, unlocked chain of
> submorphs containing it, until it reaches a leaf
>   [on its way down, any morph can install a prospective handler if
> interested]
> * when the event traverses back up the chain, the event is sent to each
> morph in this chain using #handleEvent:
> * #handleEvent: double dispatches the event into any of the system-level
> handlers
> * the system level handler (#handleMouseDown: etc) decides whether to invoke
> the user-level handler(s)
> * finally, the user-level handler (#mouseDown:) is invoked.
> 
> Cheers,
>   - Andreas
>