The little yellow dot -- SystemWindow resizing

Jesse Welton jwelton at pacific.mps.ohio-state.edu
Tue Jul 17 00:34:29 UTC 2001


Jim, have you looked at my CursorsForResizing changeset?  It provides
resize cursors instead of visible yellow dots for both window resizing
and subpane resizing, using the old mouseEnter/mouseLeave event logic.
I have had it in mind that this old logic should be replaced with the
simpler sort of logic you're using, with transparent resize handle
border morphs, but haven't got around to it.  Perhaps we should look
into folding this work together.

What I think my code really has to offer is (1) support for the
fastDragWindowForMorphic preference, and (2) software-hardware cursor
transitions, including full multi-hand support.  (Try evaluating
    World activeHand showTemporaryCursor: Cursor crossHair
and then play with your WindowFrameTest morph.  Or open an
EventRecorderMorph, then record and play back a resizing interaction.)

Jim Benson wrote:
> 
> > I would prefer the corner handles to be L-shaped, too, rather than
> > rectangle-shaped, so you can have a, say, 2-pixel border but have the
> > "corner" extend 16 pixels along the edges.
> 
> There are a couple of ways to attack this. First come up with a complex
> shaped morph that indicates the resize region. A PolygonMorph comes to mind,
> or some fiddling around with a rectange with an exclusion area.
> 
> However, I've noticed that when I start building out window frames, most of
> the corner rectangular areas will be occluded by other morphs. Cleverly
> placed, outside elements can just cover up the area in question.

I think I would prefer for the resizer morphs to be on top, for two
reasons.  First, it allows them to be wider than the visible window
frame.  This means they will overlap the window content by a few
pixels, but that's okay because the content near the window's edge in
all cases I'm aware of will still be handlable over several additional
pixels, at least.  This essentially gives you a wider grabbable resize
handle without wasting the visual space with content-free wide
borders.  Second, it would work better for subpane resizing handles,
because it is important to be able to have visually thin separations
between related subpanes, but you still need a wide enough resizing
region to grab.

  [fastDragWindowForMorphic]
> Personally I don't use that preference, but if the lynch mob clamors enough
> ...

Certainly I would be up in arms if that behavior disappeared.

As I mentioned at the top, multi-hand support would be good, too.
This will be important for collaborative environments to really reach
their potential.

-Jesse




More information about the Squeak-dev mailing list