Joshua Channing Gargus wrote:

> 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.

Yes. That was my argument against letting _just_ the Morphs decide.
There's a kludge in the code right now (see Morph>>preemptsMouseDown:) that
allows you to pick up, say, a button morph from a parts bin. But it's very
special-case,
and doesn't work for anything but mouse down events.

Lex's suggestions about the editor dispatching events (and keeping track of
tools per-Hand) sound good to me:
It would make sense to route events through the editor/world (playfield), but
that doesn't provide for different modes for each Hand, unless the editor
keeps track of an active tool for each Hand (as Lex suggested). This can
be done easily enough, of course.

This also doesn't necessarily let events "leak through" a playfield to
the Morphs below (unless there's some provision for this separately);
this is probably a good thing most of the time.

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