Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/18/84; site dciem.UUCP Path: utzoo!dciem!mmt From: mmt@dciem.UUCP (Martin Taylor) Newsgroups: net.micro.mac,net.cog-eng Subject: Re: menubar items without menus? (suggested enhancement...) Message-ID: <1701@dciem.UUCP> Date: Mon, 7-Oct-85 17:25:03 EDT Article-I.D.: dciem.1701 Posted: Mon Oct 7 17:25:03 1985 Date-Received: Mon, 7-Oct-85 19:45:51 EDT References: <3281@nsc.UUCP> <5387@mit-eddie.UUCP> Reply-To: mmt@dciem.UUCP (PUT YOUR NAME HERE) Distribution: net Organization: D.C.I.E.M., Toronto, Canada Lines: 53 Summary: The following was a response to a proposal that menu-bar items on the Macintosh should be allowed to cause "real" actions rather than just calling up window-blind menus. >I don't like your proposal, primarily because it is confusing to use the >menubar for multiple things in this way. By the way, Switcher does >something like your proposal, with its double-arrow icon at the >righthand end of the menubar; while it doesn't really confuse me, I can >imagine that it would confuse less experienced computer users ("the rest >of them"), especially since one has to be very precise and point at the >correct little arrow head. > >There are several command styles that I have seen which provide the >functionality you are describing. First of all, you can have ordinary >"Next/Forward/Previous/Backward " menu items, but have command key >equivalents; this is probably the most standard way to do this, and it >provides the simplicity that novices need and the shortcut that >experienced users want. Another possibility is to use Forward/Backward >buttons somewhere in the window. Finally, a method I have seen in some >software (although I don't fully approve of it) is to make use of the >horizontal scroll bar when real horizontal scrolling doesn't apply in >the current context; the standard Scrapbook DA does this, although I >would much prefer real scrolling, or at least the ability to resize its >window (I seem to be digressing). >-- > Barry Margolin Why should it be confusing for a menu-bar item to cause an action other than presenting a new menu? The menu-bar provides a menu. Clicking on a menu item does something. Sometimes that something is to call down another menu, sometimes it is not. Sometimes items in the window-blind menu call up a third-level menu, sometimes not. Personally, I'd much rather have a menu item "Quit" on the menu-bar than to have it as the only entry under "File", as it is in several applications distributed over the net. (Why "File", anyway? What's that got to do with quitting?). The suggestion about loading other controls, such as scroll bars, sounds much worse, since those items do have specific functions in the usual case. Forcing the use of command keys is bad: in my view, command keys should apply ONLY to visible menu items, and a new set of command keys should be available when a sub-menu is alive. For example, ^F (clover-F) might call the "File" menu, and ^S could be "Save" under that menu, so that ^F^S always meant "Save". That way, there would be compatibility between what is done at the keyboard, as well as the possibility for giving every menu item a commend-key equivalent, be it two, three, or more keystrokes. The only cost of that would be that only those functions on the menu-bar could be performed with one keystroke. I don't consider that a problem. -- Martin Taylor {allegra,linus,ihnp4,floyd,ubc-vision}!utzoo!dciem!mmt {uw-beaver,qucis,watmath}!utcsri!dciem!mmt