Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uwm.edu!zaphod.mps.ohio-state.edu!tut.cis.ohio-state.edu!purdue!mentor.cc.purdue.edu!pur-ee!pur-phy!cca
From: cca@pur-phy (Charles C. Allen)
Newsgroups: comp.sys.mac
Subject: Re: System 7 question
Message-ID: <2964@pur-phy>
Date: 5 Jan 90 13:34:48 GMT
References: <10734@claris.com> <578@sunfs3.camex.uucp> <1353@unocss..unl.edu> <5199@mnetor.UUCP>
Organization: Purdue Univ. Phys Dept, W.Lafayette, IN
Lines: 40

>> ...instead of putting the menu IN the window, replace the Title Bar
>> with a MenuBar, Perhaps in a format such as:
>>  AppName  File   Edit   Menu     Menu   Menu     ZoomBox

>> The only problem I can think of now with it is small-width windows
>> woudn't provide all the menus, but again, that can be handled by
>> MF, just by providing "scrolling" of the last menu as you go off
>> the edge of the menubar with the button held down.

> People have enough trouble with hierarchical menus.  I'm not sure if a 
> scrolling menu bar is the best approach.

DECwindows handles this by wrapping the menubar around, as in

	File  Edit  View  Special  Color

becoming

	File  Edit  View
	Special  Color

I have no difficulty using wrapped menubars.

>Having the menu bar in each window also takes up more screen space 
>overall.  It also seems that it would be harder for the user to use the 
>menus.

Screen real estate is a problem.  On the other hand, having the menus
that apply to the window I'm in *right there* makes it much easier to
understand what operations make sense & doesn't force me to move my
head up to the upper left corner of a big screen all the time.  A
reasonable arrangement would be to have the screen menubar be reserved
for operations affecting the entire application (open a new window,
global preferences), while the window menubar has operations affecting
the window contents.

I would hope that the Apple HIG people have already been looking into
these questions.

Charles Allen		cca@newton.physics.purdue.edu