Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!att!ucbvax!agate!agate.berkeley.edu!nj
From: nj@magnolia.Berkeley.EDU (Narciso Jaramillo)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: Selecting curves.
Message-ID: <NJ.91Apr2102832@magnolia.Berkeley.EDU>
Date: 2 Apr 91 18:28:32 GMT
References: <1804.tnews@templar.actrix.gen.nz>
Sender: usenet@agate.berkeley.edu (USENET Administrator)
Organization: Postcarcinogenic Bliss, Inc.
Lines: 59
In-Reply-To: jbickers@templar.actrix.gen.nz's message of 1 Apr 91 05:41:42 GMT

In article <1804.tnews@templar.actrix.gen.nz> jbickers@templar.actrix.gen.nz (John Bickers) writes:

       Oops, I accidently deleted the article this is a followup to. The
       question was about selecting a curve, and a proposed solution which
       involved rendering the curve and checking each point for proximity
       with the mouse.

       Another approach, a lot simpler, and the one I'd use (ha, some
       recommendation, huh? :) is to have a pick box associated with the
       curve.

That certainly is much simpler, and possibly more elegant, depending on
your application.  However, I don't plan to adopt it for my object-oriented
drawing program, for several reasons:

1. Pick boxes clutter up the screen, and a pick box for every object would be
   rather obtrusive.  There are several ways to fix this:

   a. Have a toggle between showing pick boxes and not showing pick boxes.
      This would cause a lot of redrawing every time the user wanted to see
      her diagram without obstruction.

   b. Only allow the user to select objects in a special selection mode,
      then only show pick boxes in that mode.  I want the user to be able
      to select objects whenever she wants, though; I plan to have a keyboard
      qualifier that drops the user into select mode.  As with (a), this would
      cause drawing and erasing of pick boxes every time she goes into select
      mode.

   I'd rather have the user select an object first, then display its control 
   points for reshaping.  That way, only the selected object(s) have their
   control points shown.  The user can dismiss the control points by
   selecting empty space or another object.

2. If you've got a big filled object on the screen, it's going to be very
   frustrating if you have to go up to the corners to select a little pick
   box rather than just clicking on the object.  Similarly, if you've got 
   a thick line or curve, I'd rather just click near it than move the mouse
   all the way to a pick box.

3. While ambiguity is a problem with pick-sensitivity-based selection methods,
   it's also a problem with pick boxes, where you often have things connected
   to each other at their control points.  Of course, this doesn't happen as
   often as pick ambiguity in my scheme; but I think that pick ambiguity can
   be alleviated by providing some easy method of cycling through possible
   selections.  (This is kind of a weak argument, I know.)

Of course, all this reasoning would be moot in the face of actual
experiments with real people trying out both types of selection
interface.  I haven't done any such experiments, so I'm basically
just designing it to fit the rest of the interface.

If anyone has experience with both selection-by-pick-boxes and
selection-by-object-hit and prefers one over the other, please send me
mail explaining why.  I'll summarize the results to the net, if
there's enough response.

--
nj			    nj@teak.Berkeley.EDU	     ...!ucbvax!teak!nj