frontend redesign :-)

[Eric Dean Tribble <tribble>]

Date: Wed, 20 Sep 89 04:56:30 PDT
   From: michael (Michael McClary)

   (The description is so graphic that my fingers itch for a mouse...)

My fingers have itched to do this style of interface for several years....

   I think I prefer an explicit icon for the group to the Macintosh
   idiom "mouse-down sorta on the selected group grabs the group".
   That makes your cursor modeful, and I often have trouble figuring out
   where a mouse-down will grab the group, and where it will deselect it.

   Hmmm... "Click" on a singleton is "select/deselect", while "double click"
   is "show/hide children".  For a set-of-selections floating button,
   "double click" is "copy/move".  Is there any reasonable operation that
   could be thought of as "open/close" for a set of selections?  Is

Sort of.  If we choose to represent groups of siblings in which some
of the siblings are collapsed, then the close operation collapses a
set of siblings into a thin dashed line or some such to ge them out of
the way (I really want this feature, but it can certainly wait for rev
2).  The dashed line would then become the button to reopen the
collapsed siblings.

   "(single) click" defined?  (Zero-length drag?  Deselecting a group
   would make the group button vanish - not nice.)

   Aha!  Double-click could be "nail it down here".  This opens space
   AROUND it.  Double-clicking again it unnails it.  Now you need a
   replacement for the copy.

   How about double-click beside a floating button for "make a copy of the
   button (and thus what it represents) appear.  Downsides:  Your cursor
   becomes modeful again, and a near-miss could do the wrong thing.

   Peahaps double-click in never-never-land could mean "Make a copy of the
   floating button for the current designated-group here"  Single-click
   without drag would make it go away, but another double-click would get it
   back.  (Not nice.  You could always get rid of it by throwing it in a
   trashcan-equivalent.)  This would have the advantage that you wouldn't
   have to drag across multiple screens when copying, but the advantage
   would be missing for move.  Hmm...

It's important not to change the behavior of anything else on the
screen when the button appears.  That means that we can't have a
special behavior for clicks near the selection button, nor should we
change the behavior of the mouse over text.

   Naw, it's getting baroque.  Why a nail-down when you could just leave
   it there?  (Letting go the button would open the space, dragging it
   out and letting go would close it.)  Let's skip symmetry, and keep
   double-click on a selection-shorthand button meaning duplicate.  (That
   means you need the floating button even if only one thing is selected.)

We could have a save bar somewhat like the icon doc of the next
machine.  If you move a selection icon over a particular spot (the
right border?) it wouldn't go away when the user made some other
selection.  The scheme that I prototyped in viewers for saving a
selection let you just drag the selection icon over the desktop
background and leave it there.  You could late pick it up and put it
in some other text.

dean