Ned Konz wrote:
> 
> > > While we're at it, let's get rid of resize handles, too.  I
> > > have trouble clicking them when I want, yet I seem to click
> > > them all the time when I don't mean to.  Instead, I'd rather
> > > a SystemWindow's panes are real morphs.  Then, I can resize a
> > > SW pane the same way I'd resize any other
> > > morph: blue-click then use the yellow handle.
> 
> Absolutely. The handles don't work at all on pen-based systems; they depend 
> on mouse-over detection!

One aspect of this window frames project is that it will make the
resizing frame/handles easier to grab in pen-based systems.  It should
be possible to configure it to use different thicknesses of frames,
too, to accommodate different screen resolutions and such.

One problem with using halos for resizing is that they're totally
inappropriate for many deliverable applications.  They're also more
inconvenient, requiring at least one additional UI gesture.  I agree
that it would be nice to be able to use them for resizing window
subpanes, but (a) I think that would be tricky to implement, and (b)
it would be especially annoying to have to drill through many submorph
layers just to be able to resize a pane.  (Look at a browser's code
pane.  Do you resize the AlignmentMorph, or the PluggableTextMorph?
Since you can only resize at the bottom right-hand corner, what effect
would this even have?)  So morphic halos as the *only* resizing option
would be, IMO, a UI disaster.

Perhaps what is needed to make the UI easier for pen-based systems is
instead a new PenHand which maintains its own button state, toggling
it based on the penUp/penDown cues from the raw event stream.

-Jesse