On Thursday 13 February 2003 10:15 pm, Ned Konz wrote:

>
> The listeners are for global hooks. This is currently mostly used by
> the EventRecorderMorph, but I think I've used it for eToy keyboard
> stuff too. These are recipients who otherwise would not get these
> events.

	Yes, that is what I was trying to say...

> Look at MorphicEventHandler>>dispatchMouseDown: anEvent with: aMorph
>
> The handler is on a per-event basis. Morphs *do* tend to have
> semi-permanent handlers, but this gives different morphs in the
> ownership chain the opportunity to handle events. The actual
> "handler" that is installed in this case is just the morph itself.
> That is, each morph can say "I want to handle this event if no one
> else does".

	Yes, but this seems needlessly complex.

	Morphs should 
	1) set the event they are intrested in
	2) Decide whether or not they want to respond to it
	3) 'Consume' it, or pass it down to their children. 

	Most other widget/tool/drawing sets take this approach. This is clean 
and straightforward. And it's smalltalk, you can reg/dereg event 
handlers at any time if you wanted. Heck, you can do it in C with 
enough function pointer pain.

	This just seems so bizzare and needlessly complex.			     	

>
> So each more innermost morph can see whether a higher morph (one of
> its parents) has set a prospective handler yet. It's possible to
> override this, of course; if you look at (say)
> Morph>>handlerForMouseDown: you'll see some logic that takes into
> account (for instance) mouseDownPriority.

	But how can a parent morph know whether or not a child wants to handle 
it? It should simply be "I want to consume it" (essentially stopping 
any response of a child), or "I'll respond, and pass it on" And this is 
really only important in the cases of morphs nested inside each other 
for widgets, etc. Two overlapping non-nested morphs should each get a 
chance to respond to mouseclicks....

> > 	This seems bizzare. So an event goes all the way to the bottom
> > before coming all the way back up and possibily being handled? What
> > is the reason for this?
>
> To let the decision of where an event will be handled happen at any
> level of the hierarchy.
>
> The problem is that we want Morphs to be able to live on their own
> and respond to interaction, as well as to live as part of other
> Morphs. So their event handling depends on their context. This is a
> way to present the requests of their enclosing contexts to them.
>
> > 	Or wait, is this to make handling changes (caused by handling of
> > the event ) in submorphs of a parent morph easier for the parent
> > morph?
> >
> > 	Here's another question then....
> >
> > 	Parent has ChildA, ChildB, ChildC, all of who are leaves...
> >
> > 	It forwards EventFoo to each.
> >
> > 	EventFoo bounces back from the Children after being handled by
> > them... So does that mean the parent sees EventFoo bouncing back up
> > 3 times?
>
> No, because only one of them at most would want to handle the event
> (ordinarily, they'd reject the event if it happened outside of their
> bounds).
>
> And anyway, it's not a bounce, rather it's a recursive method that
> sets a handler, then calls its submorphs, then looks at what happened
> (whether the event was handled, whether a handler was installed,
> etc.).

	Okay, I'm kinda starting to grok it now...

-Daniel