[comp.sys.atari.st] Menu Bars

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

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

page@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