On Tue, Aug 07, 2001 at 06:15:09PM -0700, Andreas Raab wrote:
> Josh,
> 
> The entire issue of tools is a very interesting one in object systems. 

Indeed.

> In
> effect, it raises the question of whether a tool "should be applied" to an
> object or whether an object "should provide a service" if stimulated with a
> certain tool. In my understanding, the latter is almost always the better
> way to go although I do understand that changing existing (e.g., predefined)
> classes is not always a good thing to do.

Could you point me at some literature on the topic?  The only thing I've read
wrt tools in object-oriented GUI frameworks was a paper on InterViews.

> Leaving the above issue aside, I do understand that there's some interest in
> having some sort of a "passive" mode for morphs where they're basically just
> "probed" and control is handled by some specialized mechanism (call it tool
> or custom event handler or whatever). The way I would go about this is to
> define a common protocol that's hooked right into the core of Morphic. E.g.,
> one way to do this is to define that a hand can hold (either one or a number
> of) tools, and, if so, uses a well-defined interface for doing the right
> thing. The protocol should probably be capable of figuring out whether a
> certain tool is applicable to some object (for either entering, leaving,
> clicking, or dragging) and tell the tool what it is being applied to. At
> which point it is in the responsibility of the tool to either apply itself
> to the object or to request a service from the object.
> 
> Any takers?!

I take, I take.  Expect requests for advice (not now: errands to run).

Thanks,
Joshua

> 
> Cheers,
>   - Andreas
> 
> 
> > -----Original Message-----
> > From: squeak-dev-admin at lists.squeakfoundation.org
> > [mailto:squeak-dev-admin at lists.squeakfoundation.org]On Behalf
> > Of Joshua
> > 'Schwa' Gargus
> > Sent: Tuesday, August 07, 2001 9:20 AM
> > To: squeak-dev at lists.squeakfoundation.org
> > Subject: Re: Custom Event Handler
> >
> >
> > On Tue, Aug 07, 2001 at 08:43:37AM -0700, Andreas Raab wrote:
> > > Josh,
> > >
> > > > However, I can't figure out how to get access to
> > > > mouseEnter/Leave events without generating my own
> > > > by watching when and where mouseOver events happen.
> > > > It seems that the processEvent:using: hook just provides
> > > > access to the raw hardware input events, and not to
> > > > events that are subsequently derived from
> > > > these events.  Is this correct?
> > >
> > > Almost. Enter/leave events are generated based on which
> > morphs the hand is
> > > currently "over". This is determined by sending mouse over
> > events which are
> > > handled by morphs in such a way that they tell the hand if
> > the event ends up
> > > inside. Based on this information, the hand sends enter/leave events
> > > directly to those morphs.
> >
> > Yes, this was my understanding after reading the code.
> >
> > > Note that we really can't go through the event
> > > dispatcher here - we need to figure out what has changed
> > since the last
> > > mouse position which is different from just delivering an
> > event to the right
> > > receiver.
> >
> > Perhaps I'm a bit confused about the intended purpose of the hook
> > provided by processEvent:using:
> >
> > > > Can anyone with experience with custom event handlers suggest
> > > > another way?
> > >
> > > For what? I don't quite see how one would reasonably
> > implement a dispatch
> > > strategy for enter/leave. I'm also a bit confused about the
> > subject of your
> > > message - what you're describing in the above means you're
> > changing the way
> > > events are dispatched (e.g., delivered); not how they are
> > handled. Perhaps
> > > you can explain what you're trying to achieve?!
> >
> > Your confusion is entirely based on my confusion.
> >
> > I'm implementing a drawing app where there are multiple 'tools'
> > available, one of which is active at any given time.  Depending on the
> > tool selected, mouse actions have different effects.  For example, if
> > the 'selection' tool is active, clicking on a morph will toggle
> > whether it is selected.  If the 'delete' tool is active, clicking on a
> > morph will delete it (and possibly other morphs in its group).
> >
> > One reason that I care about mouseEnter/Leave is that I want all
> > morphs in a group to be highlighted whenever the pointer enters any
> > morph in the group.
> >
> > An alternate approach that I discarded involved installing my own
> > event handlers.  In effect, edited morphs would be told: "Whenever the
> > mouse enters or leaves you, tell the drawing app and let it decide
> > what to do."  This is problematic because I might want to edit the
> > graphical properties of morphs that already have their own event
> > handlers.
> >
> > I suppose that I could hack EventHandler so that each event type is
> > associated with a collection of target/selector/argument tuples,
> > instead of a single one.  #on:send:to would then add the tuple to
> > the event handler instead of replacing it.
> >
> > Does this sound reasonable?  Do you have another suggestion?
> >
> > Thanks,
> > Joshua
> >
> >
> > >
> > > Cheers,
> > >   - Andreas
> > >
> > >
> >
> >
> 
>