u-jmolse%sunset.utah.edu@utah-gr.UUCP (John M. Olsen) (06/18/88)
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. It seems like this would be reasonably easy to do, and
would make for really useful :^) 45 level menus and such. Sure, it would
take a bit of care to make all those sublevels easy to find, and not go
off the edge or bottom of the screen, but it would add quite a bit of
flexibility to the interface. This would also make it easier to include
the interfaces to currently running programs (like the discussion about
those silly extra windows all over the place).
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 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.
"To iterate is human. To recurse, divine." -unknown
/| | /||| /\| | 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
mp1u+@andrew.cmu.edu (Michael Portuesi) (06/19/88)
> *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. > 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. > 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. More disturbing is the limitation on the number of items that can appear on a Workbench menu. The browser option in MG has gone nuts on directories containing too many files to fit in one menu. Also, the menus do not scroll if they are too large for the screen, and menus that go off the right edge of the screen are not clipped; they simply wrap-around onto the left hand side, causing some really unsightly effects. It does not look like allowing more items on a menu is feasible, though, as that would involve changing some fields in the Menu structure that would probably break a great many programs (like just about all of them). --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"
u-jmolse%sunset.utah.edu@utah-gr.UUCP (John M. Olsen) (06/20/88)
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