Path: utzoo!attcan!uunet!mcmi!hdr!unocss!dent
From: dent@unocss.UUCP (Dave Caplinger)
Newsgroups: comp.sys.mac
Subject: More Finder Improvements
Keywords: window menubar finder multifinder
Message-ID: <507@unocss.UUCP>
Date: 19 Nov 88 04:50:52 GMT
Organization: U. of Nebraska at Omaha
Lines: 80


    I'm quite happy about the surge of discussion that's being seen
here regarding the Mac's [Multi]Finder interface, and thought I'd toss
in a few more comments.

    I use an SE normally, and a Mac II every once in a while, and I don't
think that clicking a menubar inside a window is all that difficult, (for
example, QuicKeys) but I'm willing to admit this may have something to do
with the screen-size of the machine.  Perhaps the large-screen monitors,
mixed with the admittedly inadequate menubar "way up there" has created the
"fling the mouse at the top" technique now commonly used by Mac users with
large monitors (myself included, when I use the II).

    Obviously, Large- or Multi- monitor environments will probably need
/some/ soultion to this, but other than "menubar in the window", (since
it's the most logical extension of the current interface that I can think
of), I don't know exactly what that solution should be.

    Something else that might contribute to it is the inadequacy of the
current "mouse" CDEV.  I propose that the mouse "speed" should be in a
direct relation to the size of the monitor (in pixels).  Can anyone out
there stand using the mouse in "tablet" mode on a Radius 2-page display?

    I don't, however, think that anyone would mind having horizontally-
scrollable menubars, whether or not they were in the windows. :-)
(What do we do now, mass-mail to Apple in the hopes that they might care?)

    Another winner (IMHO) is the "UNDO" command.  I meant to mention this
in my original posting, but neglected it.  Something else I neglected to
mention (or even put on the example windows) was a "background" button that
someone else has already mentioned.  There would only be a need for one of
them (unlike the Amiga's interface), since clicking on the window (or
selecting it from a proposed "Window" menu if it's "hidden") woudl bring it
back to the forground.  This button would both 1) send the window to the
back of the "stack", and 2) in mutli-tasking environments, make the process
run in the background, assuming that it can run on it's own without user-
input.

    "Focus follows mouse pointer" schemes are just plain out.  At least,
I don't think they should be used for overlaped-window environments.  In
the tiling-window environment of CMU's Andrew window manager, where I 
generally had 4 (sometimes 6) windows open and running at once, I could
"fling" (guilty again) the mouse into the corner of the area I wanted, which
wasn't so bad at all.  Well... it wasn't "untolerable" at least.  I seldom
tried to type into windows I had not moved the pointer into. :-)

    I agree completely regarding modal dialogues stopping everything.
(short, and to the point)  But certainly, you should not be able to just
cover up a "Save this document before you quit and lose it all?" dialogue
and forget about it;  Maybe not being able to close the "affected" 
application is enough, as long as the Finder reminds you that there are
open applications before you simply "Shut Down".  This would also be
relevent if "hidden" windows (or groups of windows, in the case of programs
with pallette windows, etc) are allowed.

    One comment that I /don't/ agree with is putting disk and trashcan
icons in every window.  I think this would be very confusing; and tedious
to implement besides.  (Once you click on the trashcan, for example, Finder
has to go find all the windows in which a trashcan is visible, and high-
light it...)  Now, a mapping of the ammount of space used by the application's
windows (this size is variable depending on the application) into the
window "virtual" area, would achieve the same effect, /plus/ would improve
compatability (in a limited fashion) for the Plus and SE running programs
that make a window bigger than their 9" screen.  Sort of like "Stepping Out",
but hopefully without "mouse wrap around". (Which I agree, is frustrating.)

    One parting shot: If Apple decides to go the "Menubar in the window"
route, there really needs to be an easy way to define command-key equivilants.
Perhaps MacroMaker is up to this task (I don't use it, I don't know).  But,
with command key equivilants, the amount of time spent "flinging" the mouse
at the top of the screen can be reduced.  Of course, command-key eqivs are
an /option/, not a mandate. :-)  If you really want to "fling" to the menubar
to select "Copy", go for it.  Besides, "flinging" is kind of fun.


-/ Dave Caplinger /--------------+---------------------------------------
 Microcomputer Specialist        | Internet: UNOCC07%ZEUS@CRCVMS.UNL.EDU
 Campus Computing                | UUCP:     uunet!btni!unocss!dent
 University of Nebraska at Omaha | Bitnet:   UNOCC07@UNOMA1
 Omaha, NE 68182                 |   or      dc3a+@andrew.cmu.edu