Pink Plane vs Blue Plane

Andreas Raab andreas.raab at gmx.de
Sat Feb 15 18:04:13 UTC 2003


Daniel,

> 	Yes, but this seems needlessly complex.

Frameworks are designed to be flexible, to allow for experimentation. If you
can build something with the same power and extensibility by using simpler
means I'm all ears. Otherwise I see the above as a needlessly naive (and
somewhat bizarre) comment ;-)

> 	Most other widget/tool/drawing sets take this approach. 

Conceptually, yes. So does Squeak. It merely doesn't provide you with a
naive implementation. And I would be quite surprised to see that kind of
naive implementation you seem to be proposing in "most other" frameworks.
Show me one.

> 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 you gotta try ;-) How about ... having a "quit" button behind some
other morph and trying to pick up this morph?! Bye, bye... No, I really
don't think so.

Cheers,
  - Andreas

> -----Original Message-----
> From: squeak-dev-bounces at lists.squeakfoundation.org 
> [mailto:squeak-dev-bounces at lists.squeakfoundation.org] On 
> Behalf Of Daniel Joyce
> Sent: Saturday, February 15, 2003 5:53 PM
> To: The general-purpose Squeak developers list
> Subject: Re: Pink Plane vs Blue Plane
> 
> 
> 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
> 



More information about the Squeak-dev mailing list