Path: utzoo!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!iconsys!caeco!i-core!ken From: ken@i-core.UUCP (Ken MacLeod) Newsgroups: comp.sys.mac Subject: Menus in windows (Was: Re: System 7 question) Message-ID: <1990Jan14.234650.27703@i-core.UUCP> Date: 14 Jan 90 23:46:50 GMT References: <588@sunfs3.camex.uucp> <10734@claris.com> <578@sunfs3.camex.uucp> <1353@unocss..unl.edu> <5199@mnetor.UUCP> <2964@pur-phy> Organization: Bitsko's Bar & Grill, Public Access, Salt Lake City, UT Lines: 105 In article <588@sunfs3.camex.uucp>, kent@sunfs3.camex.uucp (Kent Borg) writes: >In article <2964@pur-phy> cca@pur-phy (Charles C. Allen) writes: >>[describes menu in a window, possibly/probably wrapped for size] >But we would loose an important feature of the current menus. People >can scan through the current menu bar by dragging left and right, and >select from within a menu be dragging down and up. If you wrap the >menu bar, you can't do this. It might sound trivial, but a lot of >what makes the Mac so great sounds trival. Drag down-left doesn't open/leave open the menu, same as drag-down doesn't leave hierchical menus open. Drag-down or down-right puts you "in" the menu and leaves it open. What makes the Mac so great is all the attention paid to all the things that seem trivial. 10,000 pennies is a $100, any one penny is insignificant, but they add up. >I agree that the menu bar can get pretty far away (I wish I had more >experiance with the problem--anyone want to send me a free big screen >so I can be more authoratative?), and I agree that presto-chango >nature of the current menu bar under MultiFinder is confusing. I'll take pop-ups and a second mouse-button myself. An INIT to put menus in a window shouldn't be too difficult. A little work on the window manager and default WDEFs to make "inMenuBar" come from the WDEF instead of the window manager, the app will still call the Menu Manager. A little kludge to re-find the window (since only the cursor is passed to the Menu Manager, not a Window handle) and maybe the addition of a Menu handle to a window object (so that menus are window-tied and not application-tied.) [What about custom WDEFs? Long Term: definition of how to interface to the Menu Manager from a WDEF. Short Term: a kludge to add the menu above the drag bar (ick) or a separate modeless vertical menu window (maybe we should skip the whole menu-in-window bit :-) ] As I mentioned, I'll take pop-ups. But I think the original decision for a menu-bar, on the assumption that only one program was running, was to make it always there and easy to get to. Now that multiple apps are running, I think putting it in the window is best to acheive the same ease-of-use and "always there" feeling. On the always there feeling, and keeping the one button mouse, and having pop-ups, and not using screen real-estate, I haven't heard any mention of a "Menu Region" in the title bar. This would be fairly large control, about two to three times the width of a scroll bar and almost the height of the title, that produces a vertical (or pie for you power users :-) pop-up. Command-click or second button would be a short-cut and produce the menu "here" instead of "there". (Note that command-click is style-guided for disjoint text selection (does anyone use that?) and is surely used elsewhere.) Currently defined pop-ups are style-guided mainly for item selection, and in doing define that the menu comes up with the current item under the cursor. Pop-up generic menus would most likely appear with the cursor to the left of the second to fourth item (contrast this with the style-guide, on pull downs, the second is the easiest to hit). Very nicely, this would put the "Edit" just above the cursor and the first and second items of the App's menus to the right and just below the cursor. >Another problem: What if an application has more than one window open? >Do they all have the same menu? That's not a problem, that's a solution! Document windows are almost by definition different contexts, the set of checked, enabled/disabled, and show/hide items are different. > Do different types of windows have >different menus (making them look like different apps)? Is there a >master window which has the single menu bar? 1. Yes, 2. No. Documents are documents. Layering, I understand, is a hack for applications that have tool or object attributes windows that are associated with the document window. I assume it was a choice of layered apps or losing the tool windows in the shuffle. There should be a way to make documents "layer aware". So for (2) you could have one modeless menu, tool, or object window always pulled to the front _with_ a document that uses it. But the other documents would not be pulled. Documents are different conceptual objects. I guess what I'm saying is that a document is tied to a menu or toolchest, but documents aren't tied together by an "application". >Another problem: If the menu bar is no longer at the edge of the >screen, the user can no longer use the top of the screen as a >backstop. It becomes possible to overshoot. Sure, that is true all >over the rest of the screen, but it should still be understood before >things are changed. Valid point. But it can be compared to the tiny close box or the drag region, as you mention. Once the menu is clicked it would have a slopRect like that of scroll-bars. A precise click to start it, but all the looseness in mouse waving you need to look at the menus afterwards. -- Ken [PS. I'm in need of a job. I'm looking for work in advanced technology, system software, language, and interface design. If the above kind of design thinking, tied with the ability to implement it, interests you, contact me at +1 801 255 3607, +1 801 269 0569, or ken@i-core.uucp. Have Mac, will travel.] -- Ken MacLeod, Barkeep Bitsko's Bar & Grill BBS, +1 801 269-0670 ken@i-core.uucp