Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!utah-gr!sunset.utah.edu!u-jmolse From: u-jmolse%sunset.utah.edu@utah-gr.UUCP (John M. Olsen) Newsgroups: comp.sys.amiga.tech Subject: Re: YAWS (Yet Another Workbench Suggestion) Message-ID: <2672@utah-gr.UUCP> Date: 20 Jun 88 06:01:39 GMT References: <2669@utah-gr.UUCP> Sender: news@utah-gr.UUCP Reply-To: u-jmolse%sunset.utah.edu.UUCP@utah-gr.UUCP (John M. Olsen) Organization: University of Utah CS Dept Lines: 67 In article 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