Understanding the new event model

Anybody reading most probably knows that there is a new event model. 
Understanding it, though, is a different matter.

The reference description is a little complex and confusing:
http://www.xwt.org/reference.html#events

Before, mouse events and keyboard events were different.  A mouse event
when from the child it activated upon, up through the box tree to the
root box.  Keyboard events hit the root box and went down through the
box tree to any listening boxes.

Now the event model is unified.  Both mouse and keyboard events adhere
to a two-way model.  What throws me about the new model is the
following:

"An event is triggered by writing the key to the value on a box. This
triggers any trap handlers which may be present. Once these handlers
have executed, XWT figures out which child of the current box contains
the mouse (taking into account that some boxes may cover up others) and
writes the key and value to that box. If none of the box's children
contain the mouse position, XWT removes the leading underscore from the
key name and writes the value to that property. Once all the traps on
that property have executed, the value is written to the box's parent.

Intuitively, XWT delivers the underscored event to every box from the
root to the target, and then delivers the non-underscored event to that
same set of boxes in reverse order. So the event travels down the tree
to the target, and then back up to the root."

Or more precisely:

"XWT figures out which child of the current box contains the mouse
(taking into account that some boxes may cover up others) and writes the
key and value to that box."

Why is this needed or useful for keyboard events?  Surely they are
completely independent of the mouse cursor which may not even be within
the parent frame whilst a user is typing away into their XWT
application.  This completely throws me.

- Charlie

-- 
Charles Goodwin <[email protected]>
Member of the XWT Foundation

The future of the net - www.xwt.org