🚀 go-pugleaf

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