dillon@CORY.BERKELEY.EDU (Matt Dillon) (04/10/88)
>The logical thing to happen if the menu-bar is larger than the window is that >it gets clipped. I imagine that in this case, you can use sliders to see >the rest of it. Huh? The whole idea is to be able to access the menu quickly, not to have to manipulate it like a window to get to the right header. >Also, just because you don't seem to have any problems doesn't invalidate >the original remark. An example in which the above might be true: >Say you have one application that uses 4 or 5 different menu-bar headers >that are specific to its application. And another has also 4-5 different >menu-bar headers that are particular to the application. And for good measure, >lets throw in a couple of system-specific menu-bar headers (such as desk-acce- >sories, etc.). If you have a single menu-bar, you either have to crunch >them all on the same line OR keep switching menu-bars whenever the top >window changes (when another application becomes active). >I for one, think a menu-bar per application-window is a great idea. >But, of course, that's just my humble opinion. They may or may not be rational. >Tom Wolf Not rational. Taking the Amiga as an example, the menu bar you see is the one for the currently "active" application window. An application window is made active by clicking in the window (or, with one of the myrid utilities available, simply moving the mouse into the window). This has nothing to do with the number of RUNNING applications, since many can be running at once, but simply tells the computer WHICH application you want your keyboard/mouse input to go to. Placing the menu bar on the screen rather than in each individual window makes sense because at any one time, the user will be manipulating only ONE menu. So instead of having to manipulate a menu which is limited to the window width (kind of hard if you make the window really small), one manipulates a full-width menu at the top of the screen. It makes no sense to put ALL the application's/accessory menus into one menu bar because at any one time I might have a dozen installed, and I don't even want to *see* their menus until I need them, much less have said menus hinder me. -Matt
john13@garfield.UUCP (John Russell) (04/11/88)
In article <8804091916.AA20039@cory.Berkeley.EDU> dillon@CORY.BERKELEY.EDU (Matt Dillon) writes: >>The logical thing to happen if the menu-bar is larger than the window is that >>it gets clipped. I imagine that in this case, you can use sliders to see >>the rest of it. > > Huh? The whole idea is to be able to access the menu quickly, > not to have to manipulate it like a window to get to the right > header. Agree. However I did see (on TV) someone using either a Mac or Mac-II to access a menu of many, many selections - too many to easily fit on the screen. The region of the drop-down box was the same as for a fair-sized normal menu, and when the mouse moved beyond the bottom of that box the other menu items scrolled up into the active region; no need to mouse right down to the bottom of the screen. Hmmm, I'm sure there are lots of tricks like this that can be done with menus to give them more flexibility without limiting their ease of use. John -- "Bagpipers are prone to lung infections due to fungus that grows inside the bag" - Time magazine brightens my day
wes@wsccs.UUCP (Barnacle Wes) (04/14/88)
In article <8804091916.AA20039@cory.Berkeley.EDU>, dillon@CORY.BERKELEY.EDU (Matt Dillon) writes: > Placing the menu bar on the screen rather than in each individual > window makes sense because at any one time, the user will be manipulating > only ONE menu. Yah, and if you switch back and forth between two tasks in non-overlapping windows, you have to wait for the new menu bar to get redrawn each time. No thanks. > ................ So instead of having to manipulate a menu which is limited > to the window width (kind of hard if you make the window really small), one > manipulates a full-width menu at the top of the screen. But under Windows 2.0, when you want to make an application window REALLY small, you just make it into an ICON instead of a window! The app is still loaded and active, it's just been "smalled" all the way down. You can do this on the Amiga, I am told, with a program called `Iconify.' > It makes no sense to put ALL the application's/accessory menus into > one menu bar because at any one time I might have a dozen installed, and > I don't even want to *see* their menus until I need them, much less have > said menus hinder me. Maybe it makes no sense to you, but it does to me! You could select something like `global reformat' in the word processor, and then go back to your spacewar game without waiting for the `global reformat' to finish and release it's menu bar. This is, of course, opinion, both mine and yours :-) -- /\ - " Against Stupidity, - {backbones}! /\/\ . /\ - The Gods Themselves - utah-cs!utah-gr! / \/ \/\/ \ - Contend in Vain." - uplherc!sp7040! / U i n T e c h \ - Schiller - obie!wes
dillon@CORY.BERKELEY.EDU (Matt Dillon) (04/17/88)
:In article <8804091916.AA20039@cory.Berkeley.EDU>, dillon@CORY.BERKELEY.EDU (Matt Dillon) writes:
:> Placing the menu bar on the screen rather than in each individual
:> window makes sense because at any one time, the user will be manipulating
:> only ONE menu.
:
:Yah, and if you switch back and forth between two tasks in non-overlapping
:windows, you have to wait for the new menu bar to get redrawn each time. No
:thanks.
And how long does it take to redraw a menu bar? About 1/60th of a
second.
-Mattpage@swan.ulowell.edu (Bob Page) (04/18/88)
wes@wsccs.UUCP (Barnacle Wes) wrote: >if you switch back and forth between two tasks in non-overlapping windows, >you have to wait for the new menu bar to get redrawn each time. No thanks. Why would there be a difference between overlapping and non-overlapping windows? The time it takes to redraw the menu bar is exceedingly quick on most systems. Even if it isn't, having one large menu bar for all active (or sleeping) tasks is confusing to the user. I'd rather wait even a half second (clearly about 30 times longer than most systems would make me wait) and have an application-specific menu, than to have one menu with items like 'recalculate spreadsheet' and 'XMODEM download' right next to each other. In the end, you want the user to find and execute the menu item as fast as possible. If s/he has to go hunting for it, s/he's slowed down. Again, I claim this is academic, as most systems can redraw a menu bar fast enough that you don't have to think about it. >You could select something like `global reformat' in the word >processor, and then go back to your spacewar game without waiting for >the `global reformat' to finish and release it's menu bar. Under the Amiga OS, one window is considered the 'active input window' (ie the one window you want to be typing in) and the menu is tied to that. So after you choose 'global reformat', and (say) click in the title bar of the spacewar window, your menus are now the spacewar menus. You don't have to wait for an application to 'release' its menu bar, as each application has its own menu (along with other resources). But the key is the menu bar is always at the top of the screen, where the user can find it, and is always the menu for the 'active input' window. ..Bob -- Bob Page, U of Lowell CS Dept. page@swan.ulowell.edu ulowell!page