Hi Andreas, thanks for this piece, I wanted to put it on the Swiki, but
then noticed it was already there. Could you please review a few
additions and answer a few questions to polish it off?

First a general one - it seems from reading this that there exists a
mouse event focus. Isn't focus only relevant to keyboard events? as a
user of windowing systems, I usually assume the mouse even will be
handled by precisely whatever is under it...

Andreas Raab <andreas.raab at gmx.de> 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). 
see RemoteHandMorph>>processEvents vs. HandMorph>>processEvents

> 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.
It's not very clear here who might participate in distributing the
event. Pointers?

> 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.
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?
 
> [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].
Can you give an example?
When you say "the hierarchy is traversed down" you mean the case where
there's no focus, right?
 
> 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