Window Resizing II

Jesse Welton jwelton at pacific.mps.ohio-state.edu
Thu Jul 19 14:34:15 UTC 2001


Jim Benson wrote:
> 
> Here's the next installment of the window frame resizing stuff
> 
> http://people.we.mediaone.net/trade/Zurgle/Resizing%20Part%20II.htm
> 
> Joern shamed me in to writing a polygon based resize edge. Thought I could
> just float by ...

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.  (Alternatively, you could fake the corner
polygons with two rectangles.  But polygons are so much more flexible
if you want to do something more exotic.)

> I added minimal support for the outline dragging support since the crowd was
> growing restless. After looking through the code, it looks as if that whole
> area isn't exactly straightforward.

No, it's not straightforward.  I have a hard time following it,
myself.

>  I need to figure out where I can hitch my wagon to Jesse's code at.

Taking care of the multi-hand support should be easy.  Basically just
replace

  (Cursor perform: cursorSelector) beCursor

with

  event hand showTemporaryCursor: (Cursor perform: cursorSelector)

and check that the hand is a hardware hand before initiating outline
dragging.  (My hand cursor enhancements will take care of switching to
a hardware cursor, if possible.)

Doing pane resizing right will be a bit trickier.  The way I imagine
it happening is that windows would maintain their pane resizers as
panes are added; pane resizers keep track of which panes border them,
and along which side.  The trickiest part, I think, is extending the
resizers past border junctions to the proper length.  It would be
especially nice to be able to handle four-way junctions (as in the
dual change sorter) nicely.  The current behavior gives some really
ugly results.

(It would be possible to manually add the resizers during window
initialization, but it would be alot of work doing this for all
existing windows.  This is the way annotation subpanes are currently
handled, but I'd kind of like to go back and rework that, too, when I
have the time.)

> Most importantly, I've added a few colorful examples of what window frames
> look like when they have the resizing edges attached to them. This should
> give you a better feel for what I've been talking about. Try them out see
> what you think, and make sure to send suggestions. Note that these are not
> examples of what the window frames themselves should or shouldn't look like,
> rather I'm interested in the frame interaction and design of the surrounding
> mechanisms.

This looks good.  I would still like it to be possible to have thin
frames with the resizer slightly overlapping the window's interior.
Although you haven't demonstrated this, it does appear that it should
be possible.

> If you see any major bungling going on in the code, make sure to take me to
> task for it.

The only visible bug I could find is that with fast framing on, the
frame continues to flicker after you release the mouse until you move
the pouse away from the frame.  I haven't looked into what causes
this.

-Jesse





More information about the Squeak-dev mailing list