keith@ssc-vax.UUCP (Keith Nemitz) (10/01/85)
This is an open call to Apple INC for a possible enhancement to the Mac via
the new ROMs.
I've been examining the Amiga, which in general has a poorer user interface,
but one of it's features caught my eye. SubMenus.
The submenu is an optional menu placed at the side of an item on an already
open menu. From there, the user can select more detailed information concerning
the main item. For example, the desired fontsize of a selected font. It's
neat.
Well, that's the best I can do to make it a reality. Further discussion and
opinions on the net might sway the Apple giant into action. How about it?
keith
"...
They showed you a statue
And told you to pray.
They built you a temple
And locked you away.
..."allison@convexs.UUCP (10/03/85)
> This is an open call to Apple INC for a possible enhancement to the Mac via > the new ROMs. > I've been examining the Amiga, which in general has a poorer user interface, > but one of it's features caught my eye. SubMenus. > The submenu is an optional menu placed at the side of an item on an already > open menu. From there, the user can select more detailed information con- > cerning the main item. For example, the desired fontsize of a selected font. > It's neat. > keith I don't know about this! First of all, you can always do like Microsoft Word if you want sub-menus. However, I think that is one of the main weaknesses of Word - two selections are required just to change a font! Back to the example at hand, what if the user wanted to change the fontsize without changing the font? Are you still going to require him to select the (same) font? Or are you going to have another menu, for font sizes, in this case? Sounds like this idea is a waste of ROM space. There probably are cases where the submenu idea is valid, but I doubt if that is the general rule. Brian Allison {allegra, ihnp4, uiucdcs, ctvax}!convex!allison Convex Computer Corp. - OR - Richardson, TX {allegra, ihnp4, uiucdcs, ctvax}!convex!convexs!allison
usenet@ucbvax.ARPA (USENET News Administration) (10/04/85)
Um, unless I'm mistaken, the Mac already supports sub-menus in a way that the Amiga never will. You see, you can define you're own menu types. If you notice the rightmost menu "Keypad" in MacTerminal, you've got an example of a custom menu-type. To make a sub-menu, you'ld simply define you're own menu type. True, it's not supported by the OS routines in that the Mac will tell you which item in the sub menu you called, nor will you be able to make command-key assignments the way you would for normal menus, but you still can have them. The major trouble with sub-menus, it seems to me, is exactly how you would implement them. I personally dislike the way the Amiga did them. It lacks the polish and class of the Mac's envorinment. I'm not quite sure just how I'd implement them myself. But!!!, if you really want Apple to do something such as this, I'd suggest that you make a program w/sub-menus (custom ones) and then send a copy to Apple and the net, to get a response. I'd like to see such myself, but I'm not sure whether it can be done in a smooth, clear, and polished way.
warack@aero.ARPA (Chris Warack) (10/07/85)
overlap the first menu. The first item of the sub-menu would be next to the main menu item. If the user moves the mouse directly on the sub-menu (still dragging), he can then choose any item on the sub-menu just as if it was a main menu. If he moves the mouse back to the main menu and/or away from the sub-menu item on the main menu, the sub-menu disappears. In summary, the sub-menu works like a main menu, but instead of being pulled-down from the menu bar, it is pulled down by high-liting its item in another menu. The advantages of this: It can be used to keep menus less cluttered by allowing more levels of grouping. It is much faster than using dialog boxes. It could be easily implemented -- just allow menu items to include menus (thus menu-select and other toolbox calls would return the correct codes and they could be stored as menu resources and used in menu bars as well -- sub-menus would have to have unique menuID's of course). Disadvantage: Although I said easy to implement above; I meant this on an application level. It would require some low level witchery by Apple to implement. Note that this kind of implementation would allow (theoretically) a number of nested sub-menus. What do people think? BTW, how does the Amiga do it? Chris -- _______ |/-----\| Chris Warack (213) 648-6616 ||hello|| || || warack@aerospace.ARPA |-------| warack@aero.UUCP |@ ___ | {seismo!hao | tektronix}!hplabs \ |_______| !sdcsvax - !sdcrdcf!trwrb!trwrba!aero!warack || || \ Aerospace Corporation, PO Box 92957, LA, 90009, Station M1-117 ^^^ ^^^ `---------(|=
granvold@tymix.UUCP (Tom Granvold) (10/11/85)
- Yes the Amiga has submenus that come out from the side of the main menu, at least my Amiga has them :-) As far as I can tell on the Amiga only one level of submenu is allowed. Tom Granvold ucbvax!allegra!olivab!tymix!granvold
lamy@utai.UUCP (Francois Lamy) (10/14/85)
In article <492@aero.ARPA> warack@aero.UUCP (Chris Warack) writes: >(...) The first item of the sub-menu would be next to the >main menu item. If the user moves the mouse directly on the sub-menu >(still dragging), he can then choose any item on the sub-menu just as if >it was a main menu. (...) > >What do people think? BTW, how does the Amiga do it? > (...) As far as I can tell, this is exactly the Dandelion approach (except of course that Xerox uses pop-up menus or menus fixed in a pane). Would Xerox sue? ( :-( , Apple!) (How do you make a face with a tongue sticking out?). Such sub-menus are very easy to use. It does not mess with the very important capability of being able to look at all the choices available through menus. Jean-Francois Lamy U. of Toronto: lamy@utai.toronto.csnet, {decvax,allegra,utzoo}!utcsri!utai!lamy U. of Montreal: lamy@iro.udem.cdn (from csnet: lamy%iro.udem.cdn@ubc.csnet) .
adams1@gumby.UUCP (10/16/85)
> Such sub-menus are very easy to use. It does not mess with the very important > capability of being able to look at all the choices available through menus. Well, I am pretty good with my mouse and I even had problems with the Amiga sub-menus. When I see others having trouble choosing things off a mac menu, or missing a push button, I wonder how hard of a time THEY would have using sub-menus. For those of you who haven't tried one, they are a pain. You go up and grab your main menu, then move down to the item you want, then you have to *carefully* navigate a ninety degree turn and go off to the right, then pick your sub-menu item. If you accidentally move too far up or down (usually RIGHT BEFORE you get to the sub-menu, then you will have chosen the WRONG main menu item, and will be on IT'S sub-menu. I invite every one to try an amiga, and then decide if this is what you really want. Dennis Adams adams1@gumby.wisc.edu
tim@k.cs.cmu.edu.ARPA (Tim Maroney) (10/20/85)
Dennis Adams made some good points concerning the difficulting of using the
proposed submenus. This can't be solved by having them pop up overwriting
the current menu, because that destroys browsing and access to lower menu
items.
One solution is directly moving the mouse location to the start of the
sub-menu, which you can do by twiddling marginally documented low-memory
globals. But if you were really trying to run down the list of menus, this
wouldn't be very nice, since you'd be back to the right-angle precision turn
that Dennis rightly complained about.
Perhaps the only easy-to-use solution would involve a fusion approach. When
the mouse passes over a menu item which opens a submenu, the submenu appears
to the right. The submenu can be directly moved to using mouse movement, or
the main menu item may be selected. If the latter, the mouse button is
released while still selecting the main menu item. This causes the menu
definition to be called with mChooseMsg. The menu definition can look at
the item, see if it opens a submenu, and if so, move the mouse location onto
the submenu and allow selection from the submenu.
I hope everyone realizes that submenus would require that extending the Menu
Manager. The popping up of submenus during mouse dragging cannot be
controlled directly by the menu definition procedure; the only way to do
this in the current system would be to install a vertical retrace task on
mDrawMsg that checks to see if conditions are such that a submenu should be
brought up or removed, removing it on mChooseMsg. That would be incredibly
kludgy, though not impossible.
-=-
Tim Maroney, CMU Center for Art and Technology
Tim.Maroney@k.cs.cmu.edu uucp: {seismo,decwrl,etc.}!k.cs.cmu.edu!tim
CompuServe: 74176,1360 My name is Jones. I'm one of the Jones boys.lewak@sdcsvax.UUCP (George Lewak) (10/28/85)
In article <610@k.cs.cmu.edu.ARPA> tim@k.cs.cmu.edu.ARPA (Tim Maroney) writes: >... >One solution is directly moving the mouse location to the start of the >sub-menu, which you can do by twiddling marginally documented low-memory >globals. But if you were really trying to run down the list of menus, this >wouldn't be very nice, since you'd be back to the right-angle precision turn >that Dennis rightly complained about. > >Perhaps the only easy-to-use solution would involve a fusion approach. When >the mouse passes over a menu item which opens a submenu, the submenu appears >to the right. The submenu can be directly moved to using mouse movement, or >the main menu item may be selected. If the latter, the mouse button is >released while still selecting the main menu item. This causes the menu >definition to be called with mChooseMsg. The menu definition can look at >the item, see if it opens a submenu, and if so, move the mouse location onto >the submenu and allow selection from the submenu. > >I hope everyone realizes that submenus would require that extending the Menu >Manager. The popping up of submenus during mouse dragging cannot be >controlled directly by the menu definition procedure; the only way to do >this in the current system would be to install a vertical retrace task on >mDrawMsg that checks to see if conditions are such that a submenu should be >brought up or removed, removing it on mChooseMsg. That would be incredibly >kludgy, though not impossible. >-=- >Tim Maroney, CMU Center for Art and Technology >Tim.Maroney@k.cs.cmu.edu uucp: {seismo,decwrl,etc.}!k.cs.cmu.edu!tim >CompuServe: 74176,1360 My name is Jones. I'm one of the Jones boys. Wouldn't it be easy just to rewrite the menu definition procedure? There is one problem though: how do you create a "window" (which overlays the other windows on the screen) and put the previous stuff back on the screen immediately after the "window" is closed (rather than after an update event). This is what happens when you pull down a menu in the menu bar - a "window" (or a grafport, or whatever) appears to show the items. Anyway, once we can do this ourselves, sub-menus should be easy by just modifying the original menu definition. Victor Romano
tim@k.cs.cmu.edu (Tim Maroney) (10/31/85)
Victor Romano: > Wouldn't it be easy just to rewrite the menu definition procedure? No. There are three messages to menus, one to draw the whole menu, one to handle mouse-ups, and one to figure out the menu size. There's no message to handle hiliting of a particular item during dragging. That's why, as I said, you'd have to use a back door, such as installing a vertical retrace task that checks the mouse, or patching MenuSelect. There are no hooks in the existing Menu Manager (none documented, anyway) that would allow sub-menus to pop up as you dragged through the menu, the proposed behavior. > There is one problem though: how do you create > a "window" (which overlays the other windows on the screen) > and put the previous stuff back on the screen immediately > after the "window" is closed (rather than after an update > event). This is what happens when you pull down a menu > in the menu bar - a "window" (or a grafport, or whatever) > appears to show the items. That part's easy! Get a block from the Memory Manager, use CopyBits to copy from the screen rectangle about to be overdrawn into the heap block, draw the menu, and when the menu goes away, reverse CopyBits and dispose of the heap block. Don't use a new window or grafPort, just the Window Manager port (saving and restoring the current grafPort, of course). -=- Tim Maroney, CMU Center for Art and Technology Tim.Maroney@k.cs.cmu.edu uucp: {seismo,decwrl,etc.}!k.cs.cmu.edu!tim CompuServe: 74176,1360 Religion is a branch of psychology.