On Wed, Oct 25, 2000 at 12:09:32AM +0000, Lex Spoon wrote:
> > > By the way, there is a way to implement "connect two things" from Ned's
> > > example in the current system.  Basically, you need a ConnectionMorph
> > > (which you probably need anyway), and you need an EndpointMorph.  When
> > > you make a click that starts a connection, create an EndpointMorph and a
> > > ConnectionMorph, connect the ConnectionMorph to the EndpointMorph and to
> > > whatever was clicked on, and then attach the EndpointMorph to the hand.
> > > When the Endpoint morph gets dropped, then the right thing happens
> > > depending on where it is dropped.  Of course it's just one example, and
> > > there are surely harder examples, but it's interesting how far current
> > > Morphic can go.
> > 
> > I've already been down that path. I have a ConnectionMorph and EndpointMorph.
> > 
> > First problem is the "making a click that starts a connection". Let's say
> > I want to connect a Rectangle to another Rectangle. I click on the Rectangle,
> > and ... oops! the Hand says "I know what a click means" and picks up the first
> > Rectangle. Well, that didn't work.
> > 
> 
> The hand will only pick something up if every morph in the "core sample"
> says that it isn't interested in the mouseDown event....  So, have one
> of those morphs say that it wants the mouseDown event.  Presumably the
> rectangle in question is embedded in some sort of EditorMorph, so the
> EditorMorph could grab the event.

Here's a scenario that may or may not reflect someone's desired usage patterns:

Imagine that the EditorMorph is used to assemble GUIs, and that the Rectangle
is to act as a button (ie: it handles mouseDown).  The editor might have two 
modes, 'assembly' (when gui elements are arranged, have behaviors assigned, 
etc.), and 'test' (when the gui acts as it normally would).  In order to
facilitate layout changes during 'assembly' mode, the editor might like to 
intercept the mouseDown so that a click on the Rectangle will not trigger
any action.

> Maybe the current system is flexible enough after all?
> 
> 
> Also, consider this case: the mouse enters an editor morph, chooses a
> tool, leaves the editor morph, and then comes back again.  Ideally, the
> same tool would remain active when the hand returns.  But where does
> this tool get remembered?  Probably each morph that wants to do
> something unusual, is going to want a dictionary mapping hands into
> hand-specific data for when the hand is absent.  But if you've already
> got such a morph-specific dictionary, there doesn't seem to be a need to
> store anything directly in HandMorph.
> 
> 
> 
> 
> -Lex