🚀 go-pugleaf

In article <gWipIgy00Vs6M48V01@andrew.cmu.edu> Michael Portuesi writes:
>> *Excerpts from ext.nn.comp.sys.amiga.tech: 17-Jun-88 YAWS (Yet Another*
>> *Workbench.. John M. Olsen@utah-gr.UU (1333)*
>> Since everyone is putting in their suggestions for worbench wonders they
>> would like to see, how about making menus really recursive instead of only
>> two levels deep.
>Well, this is really an enhancement for Intuition, not Workbench.

Whatever can get it done. :^)

>
>> All you would need was one menu for external programs, where each top level
>> entry would be a program name which could have an entire menu subsystem
>> arranged vertically instead of horizontally on the program's "main" level.
>I don't understand what you are saying.  Are you implying that other programs
>should be allowed to place their menulists in the menulist for the Workbench
>window?  If so, that is not the same thing as allowing n-level nested menus.

Sorry, I merged two topics without warning.  What I meant to say is that you
could keep menus working in the normal way they do now, but also add a 
feature to allow for programs to tap into a special new workbench menu item,
called RESIDENT or some such, where a program could install it's own menus
if it has no window to attach them to.

>
>> I haven't looked at a menu structure recently (I'm at work now) but it seems
>> that the pointers are all there and it's just WorkBench that isn't being
>> freindly about it.
>
>I'm pretty sure that the SubMenuItem structures do not have a pointer in their
>fields to hang more SubMenuItems onto.  It wouldn't have been too difficult to
>do this initially...I suspect the decision to allow only one level of nesting
>was deliberate.

I hate it when someone (deliberately or accidentally) removes flexibility.
I looked at intuition.h, and it looks like the structures could handle it
just fine.  Each MenuItem has a pointer for the item below it, and another
pointer for the sub-items.  The top level Menu structure is just a linked
list of pointers to MenuItems, with a few extra doodads like menu names.
It would only be necessary to define a new type of Message where you could
return what was selected since the current method only likes two level menus.
(correct me if this is a hallucination)  Then we could see how much more 
confused everyone gets when dealing with menus.  It would still be up to the
programmer to not make spaghetti menus, just as it is now necessary to check
for good positioning and not-too-long dynamic lists.

>More disturbing is the limitation on the number of items that can appear on a
>Workbench menu.  ...

It would be nice if there were a way to do it.  Menus could be perverted into
doing that by having MenuItems like "fonts a-e", "fonts f-j", "fonts k-o",
and then having each of them be loaded to the gills with entries.  This
would even work with the way it's set up now.  Of course it would have to be
dynamic and adjust as it read font names until you maxed out at about 400
fonts or so, which I doubt would be a problem. :^) (20 items on the first 
level, each with 20 sub items).

>                        --M
>Michael Portuesi / Information Technology Center / Carnegie Mellon University
>ARPA/UUCP: mp1u+@andrew.cmu.edu                     BITNET: rainwalker@drycas
>"if you ain't ill it'll fix your car"


 /|  |     /|||  /\|		|	John M. Olsen, 1547 Jamestown Drive
 \|()|\|\_  |||. \/|/)@|\_	|	Salt Lake City, UT  84121-2051
  |	u-jmolse@ug.utah.edu	or  ...!ihnp4!utah-cs!utah-ug!u-jmolse
"What is mind?  No matter.  What is matter?  Never mind."  -T. H. key