Newsgroups: comp.sys.mac.programmer
Path: utzoo!utgpu!jarvis.csri.toronto.edu!ephemeral.ai.toronto.edu!dudek
From: dudek@ai.toronto.edu (Gregory Dudek)
Subject: Re: Append menu is slow.
Message-ID: <89May10.154646edt.10758@ephemeral.ai.toronto.edu>
Keywords: AppendMenu menu slow efficiency
Organization: Department of Computer Science, University of Toronto
References: <89May9.171757edt.11077@ephemeral.ai.toronto.edu> <554@biar.UUCP>
Date: Wed, 10 May 89 15:46:41 EDT

Context:
>>The application I am writing needs to create some large menus; up to
>>128 items (sometimes more).  I know, that's uuuugly but I want to
>>allow selection from a long list of undifferentiated items.  

In article <554@biar.UUCP> trebor@biar.UUCP (Robert J Woodhead) writes:
>
>DO NOT USE MENUS IN THIS WAY.  It is contrary to the spirit of the Mac
>user interface.  Use a scrolling list instead, for several reasons:
>
    [some good reasons, not all of which apply to my case, deleted]
>
>Quite frankly, the fact that you are having this problem indicates that
>your user interface requires serious rethinking.  A huge list of
>undifferentiated items is a perfect example of what a user should NEVER
>be faced with, because he/she will never be able to find the thing they
>want when they want it.  If possible, menus should have <10-15 items.
>

  (Long response & justification follows...)

  This is the kind of religious dogma that keeps coming up here.
    "you are doing a bad thing.  It's against the guidelines!  It's against
    the law!  Open your eyes!"

  Sure, pointing out the potential problems with an approach may be useful.
Yes, of course I know that large menus have problems associated with 
them.  Maybe you should consider the possibility that I have a problem you 
may not have encountered before, and that this solution is might be 
appropriate in this context (despite its apparent ugliness).

   Basically, I want to be able to select items from large groups of
user-defined objects.  The objects aren't graphic and the semantics 
of the objects aren't known to the program (they are created outside 
the program).  
   This kind of situation arises in programs that support large numbers of 
user-defined macros.  It is often difficult to structure the available macros
except in a long list (either that, or FORCE the user to structure them - a bit
fascistic).
  Worse yet, in my case I may have a whole bunch of such lists.  I am
using popup menus for them.  At least they popup with the currently 
selected parameter value under the mouse.  The problem is that creating them
dynamically is to slow.

    An analogy might be drawn to a utility for manipulating different 
groups of files.  The finder does it by having lists of files pop up when 
you open a folder.  This metaphor works well when you're staying in 
one open folder for a while.  When you want to pick a file here & a file
there (or in may case, set a parameter here, a parameter there) the 
desirability of having all those overlapping lists becomes questionable.

   Since the item-lists have no structure I know of, no hierarchical
decomposition can be used.
   In short, I (still) need long popup lists that allow you to
make a quick choice, then they dissapear.  Sure sounds a lot like a
popup menu.

   My apologies for the length of this reply, but I wanted to try and
make my point fully & avoid further scolding.

   Greg Dudek
-- 
Dept. of Computer Science (vision group)    University of Toronto
Nice mailers:  dudek@ai.utoronto.ca
UUCP: {uunet,decvax,linus,pyramid,
		dalcs,watmath,garfield,ubc-vision,calgary}!utai!dudek
ARPA: user%ai.toronto.edu@relay.cs.net