> Does the Morph know that it is being drawn in a scaled environment?
> Because that's something it should know so it can draw user interface
> elements (the 'handle' triangles and circles for sure, and the outline
> in our case as well) at the appropriate scale.

Just for the records: To me, this is a fundamentally broken model when it
comes to the distinction between the UI elements and the objects themselves.
IOW, when we have a (potentially scaled) object and want to provide
(unscaled) UI elements we need to distinguish between the object and its
editor. Which could mean that (for example) we have some "polygon editor
morph" which _contains_ a (scaled) polygon as well as (unscaled) handles.
The way the handles on polygon morphs work today is a cute hack (and an
interesting example of what you can achieve by embedding "out-of-bounds"
submorphs) but it is not a good model when it comes to scaling. Typically,
scaling should be transparent for the client so if there are elements
embedded in a scaled morph, those should scale as well. Or how else would
you (without adding further hacks which would uglify the model even more)
achieve the effect that either the polygon morph _or_ its surrounding
environment is scaled? (in the first case, you'd expect the handles to stay
the same, in the second you'd expect them to be scaled too).

> >I don't understand why you feel you have to bypass Morphic. The user 
> >interaction -- the event handling especially -- is already 
> >handled by Morphic.
> >
> Well, then probably you know too much about Morphic to appreciate how
> completely lost this beginner is. If I cannot untangle the 
> code that is currently there, and at the moment it looks that way,
> it is probably faster to junk the lot and start from scratch...

An interesting statement given that (in light of the following) we're really
talking about one or two classes. What's the problem with "junking the lot
of" PolygonMorph and do a clean-room implementation? You got plenty of code
to look at how things are done and not limited by any of the existing stuff.

> Maybe we can subclass from Morph to get the event handling, 
> but all the useful stuff in PolygonMorph (our most important
> worker at this moment) and others we probably need to rewrite
> from scratch :-(.

Which (given your requirements) may actually spare you a lot of time down
the road. I think it's a good idea for your project to implement it from
scratch.

Cheers,
  - Andreas