Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!uwm.edu!gem.mps.ohio-state.edu!apple!agate!shelby!ucscc.ucsc.edu!gorn!filbo
From: filbo@gorn.santa-cruz.ca.us (Bela Lubkin)
Newsgroups: comp.sys.amiga.tech
Subject: Re: 1.4 Wish: Revamped sizing gadget
Message-ID: <62.filbo@gorn.santa-cruz.ca.us>
Date: 27 Oct 89 14:26:52 GMT
Organization: R Pentomino
Lines: 47
X-Claimer: I >am< R Pentomino!

This is in reply to a bunch of messages; I'm not going to quote what's
already been quoted to death.

Wherever the sizing gadget is, it would be nice to be able to size and move
the window within the same operation.  Suppose the current sizing gadget is
augmented so that when BOTH buttons are pressed, it becomes a movement
gadget.  While sizing the window you would be able to move it, using the
same gadget as a "handle", by holding down the right button.  This would be
very convenient no matter where the sizing gadget was.  I agree that the
current location of the sizing gadget is best for text windows, and see no
compelling reason to move it for other types of windows, PROVIDED that it
takes up no window space.

How can this be done?  One way would be to use an additional small
layer/window for the sizing gadget, so that the entire window could be
rendered into.  This leaves the problem of the gadget's area being obscured.
Suppose the gadget is not actually rendered except when it's being used.  It
could be indicated by hash marks in the window border: | and rendered only
when the mouse was within the gadget and the left      | button was pressed.
Unfortunately, this would probably be less than        | intuitive. It would
also prevent mouse clicks from being transmitted       : to the application
within the gadget's area.  On the other hand, -------..+ it would remove the
need for a separate layer, which would probably be much better from a
performance standpoint.  I suppose the gadget could also pass on a mouse
click if A) no sizing was actually done (the mouse didn't move while the
button was clicked) and possibly B) it was held down for a sufficiently
short time, probably the Preferences double-click time.

With this scheme it would be desirable for an application to be able to
specify whether the gadget should be rendered (and take up a row and a column
of the window) or not (and possibly confuse novice users) OR "no preference".
Most programs would use "no preference" -- especially since it'd be the
default, so all current programs would use it.  An option would be added to
Preferences to let the user specify the default behavior.

I see no problem at all with a single front/back gadget.  It will cause a
few extra mouse clicks here and there; will undoubtably save some there and
here; but that all comes out in the wash.  It WILL be a lot easier to use.
I still screw up on which gadget to use, after 4 years.

I doubt any of this discussion has any bearing on what will actually happen
in 1.4 -- isn't a little bit late to be designing the system when it's
already in alpha-test?

Bela Lubkin    * *    //  filbo@gorn.santa-cruz.ca.us  CompuServe: 73047,1112
     @       * *     //   ....ucbvax!ucscc!gorn!filbo  ^^^-VERY slow [months]
R Pentomino    *   \X/    Filbo @ Pyrzqxgl +408-476-4633 & XBBS +408-476-4945