Jim Benson wrote:
> 
> > You now have two resizer classes, for rectangles and polygons, with
> > alot of duplicated code.  If the polygons are okay for the corners,
> > performance-wise, it shouldn't really be any trouble using them for
> > the rectangular sides as well, and it would save you having to keep
> > the classes in sync.
> 
> That's what I think too. I just can't figure out how to make the polygons
> stay or go where I command. When I use the standard resizing tricks, the
> polygons seem to jump around by unpredictable 1 pixel increments and I don't
> know why at this point. Played with it a couple of hours but it's smarter
> than I am, and I wanted to move on for the moment. The corners are
> different, as they are fixed size. If you need some more excuses, I can make
> some more up.

Hmm, good point about the variable size of the edges.  You could
always specialize the resizing methods for your rectangular resizers.
(Either give them an isRectangular attribute, or make an appropriate
subclass.)

Or, again, you could derive from BorderedMorph and specialize the
behavior for the corners.  I believe you suggested using an exclusion
region before.  You could also delegate mouse-over testing to a
contained PolygonMorph.

> [ <snip> Pane resizing stuff  ]
> 
> Stop it. You're scaring me.

Yeah, that's part of why I didn't do it.  But much of this logic is
already there; it's just done dynamically when generating the little
yellow dots for pane transitions.  Perhaps the thing to do here is to
make a PaningRegion class which could handle pane and subpane resizing
in a unified manner, independent of being in a SystemWindow.  It would
be a good way to do experiments, and it actually sounds pretty handy
to separate this behavior out.  I'll look into it.

-Jesse