[DOCS] MorphicEvent handling (was RE: Pink Plane vs Blue Plane)

Hannes Hirzel hannes.hirzel.squeaklist at bluewin.ch
Thu Feb 13 09:06:59 UTC 2003


Hi all of the documentation team

   1. Shane Roberts shane at shaneroberts.com
   2. Brent Vukmer bvukmer at blackboard.com
   3. Hannes Hirzel hannes.hirzel.squeaklist _at_ bluewin.ch
   4. Lic. Edgar J. De Cleene edgardec2001 at yahoo.com.arj
   5. Doug Clapp dclapp at qwest.net
   6. Chris Burkert chbu at hrz.tu-chemnitz.de
   7. Marco Paga
   8. Torsten Bergmann TBn at phaidros.com 

To take up the important communication by Andreas Raab 
added below:

May I ask one or two of you to  read it, elaborate it 
(includes adding examples) and
asking further question (e.g. what is the front-most
morph or how is it detected).

Then have it proof read  by some list members
and put it up on the Swiki.

My schedule doesn't permit this in the next 48 hours.
I really do not want to see this really important
documentation nucleus disappear in byte nirwana.

Side note to Stephane et. al. I do not think that these
efforts are in vain. Documenting concepts is very 
important (read Ralph Johnson's thoughts on documentation
of June 1999 http://minnow.cc.gatech.edu/squeak/736)
But of course I support your plug for writing unit tests as well....

Hannes





---------------------------------------------------------------
The copy of Andreas email
---------------------------------------------------------------


"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). 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



More information about the Squeak-dev mailing list