On Tuesday 07 August 2001 06:15 pm, you wrote:
> Josh,
>
> The entire issue of tools is a very interesting one in object systems. 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.
>
> 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'm interested in this; I've tried a couple of different approaches already 
with my Connectors.

Having the Hand actually participate (instead of just existing as a mass of 
behavior to be carefully worked around) would be a help.

I think I'd also consider making the drag'n'drop behavior be a tool mode: 
that is, the Hand has a drag tool which has contents. This would generalize 
the (currently special case) d'n'd behavior.

-- 
Ned Konz
currently: Stanwood, WA
email:     ned at bike-nomad.com
homepage:  http://bike-nomad.com