Newsgroups: comp.sys.mac
Path: utzoo!utgpu!jarvis.csri.toronto.edu!csri.toronto.edu!vg
From: vg@csri.toronto.edu (Victor Greenberg)
Subject: Re: Finder Improvements
Message-ID: <8811170216.AA22099@yorkville.csri.toronto.edu>
Keywords: finder, undo
Organization: University of Toronto, CSRI
References: <10895@dartvax.Dartmouth.EDU> <10897@dartvax.Dartmouth.EDU> <2162@iscuva.ISCS.COM>
Distribution: na
Date: Wed, 16 Nov 88 21:16:25 EST

jimc@iscuva.ISCS.COM (Jim Cathey) writes:
(concerning menu bars inside windows instead of along the top)
>To summarize, I like where the menus are now, and I believe that the existing
>menu bar should be kept, with the menu set corresponding to the window with
>current focus.  Removing this will negatively affect the, umm, _expert_ user.

My experience is that, while the menu bar along the top of the screen works
fine with tiny screens (like the original Mac screen), it isn't so great
when you have a workstation-sized display.  I'm using a radius 2-page display.
With that much screen real-estate, it is a major annoyance to have to shift
your focus to the upper-left corner of the screen to pick a menu when you
are working on a window in the lower-right corner.  Since the world is moving
towards big screens, future window environments should be designed with
arbitrarily large display surfaces in mind.  Putting menu bars into windows
is one way of addressing the problem.

>This is not to say that there can't be some _additional_ way of doing what
>the original poster wanted.  But, how does whatever it is affect the notion
>of frontmost window is the active (focused) window?  How would you feed 
>commands to a partially obscured window given the original proposal?  Bring
>it to front you say?  Well, that already works given the current scheme.
>
>If every window had a built-in menu bar the logical next step would be to
>change the WM so that it had one of those nasty focus-follows-the-mouse-
>pointer schemes (which I detest).  That way you could feed arbitrary menu
>commands to arbitrary windows without intervening refocus commands
>(SelectWindow).  Of course, then you'd have to be careful not to knock the
>mouse pointer out of the window you're typing in or else your input will be
>lost.  Echh.  
>
>The current scheme isn't so bad, is it?  Comments, anyone?

My biggest beef with the current scheme is that it is more modal than
necessary, with its concept of a single active window.
1) I dislike the fact that if you lay out a collection of non-overlapping
   windows on the screen, you still have to click once to "bring a window
   to the front" before you can do anything else within it.  A better idea
   is to allow all non-obscured windows to respond mouse clicks instantly,
   without the need for a preliminary activation clicks.  Partially obscured
   windows would still have to be brought to the front before they could
   be used.
2) And you still need to have a concept of a keyboard focus window.
   Clicking within a window that is capable of accepting keyboard input
   would make that window the keyboard focus.  Jim Cathey is right about
   keyboard-focus-follows-the-mouse-pointer schemes: they really do suck.
   My point is that you don't need the concept of a *mouse focus* window
   as well.

While I'm beefing about modality, I'd like to complain about modal dialog
boxes as well.  The Mac user interface has far too many of them.  For
example, there is absolutely no reason for the "Open..." dialog in the
File menu to be preemptive.  Wouldn't it be nice if the file select dialog
came up in a non-preemptive window, so you could leave it in a corner
of the screen while you did something else?
  I claim that most modal dialogs should either not preempt anything at all,
or should only preempt a single window, leaving everything else functioning
normally.  For example, the "Close without saving changes?" dialog that
comes up when you attempt to close an unsaved document only needs to preempt
the document window it refers to, not the entire system.

Finally, I'd like to point out that multi-level undo is a really nice
feature to have in any program.  It's unfortunate that it isn't a part
of Apples user interface guidelines, and that there is no Redo command
in the standard Apple "Edit" menu.