dent@unocss.UUCP (Dave Caplinger) (11/19/88)
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.edugillies@p.cs.uiuc.edu (11/23/88)
1. I dislike the fact that you must always bring a window to the
front to use it. Here's why:
(a) In many editing programs (like Macdraw, MS-Word), it's
efficient to make a "palette" of frequently typed things
in a second window, then just cut & paste these things into
your document. But for maximum exposure, you'd like to hide
the herald of the palette under your main window. This herald
keeps coming up, and you keep having to put it down.
(b) In other cases, a certain layering maximizes visible screen
real-estate by hiding unnecessary junk on the bottom. But if
windows are frequently coming to the top, this stacking is
painful to maintain.
I.e. sometimes you want to be able to access a certain part of a
window, but don't need the rest. By covering up the rest,
the screen real-estate can recycled for other things.
I'm very surprised the original designers didn't anticipate
this method of squeezing everything out of the screen
real-estate, since the first Mac had a very small screen.
Don Gillies, Dept. of Computer Science, University of Illinois
1304 W. Springfield, Urbana, Ill 61801
ARPA: gillies@cs.uiuc.edu UUCP: {uunet,harvard}!uiucdcs!gilliestynor@pyr.gatech.EDU (Steve Tynor) (11/30/88)
Many of the articles I have read lately seem to be saying "It's hard to get the mouse up to that menu bar." I have a suggestion that I'd like to throw out for everyone to chew on: Have a keyboard shortcut to move the mouse to the top of the screen. This gives you a quick way to get at the menu bar without taking up any precious screen real estate. Then, when you release the key(s), the mouse would return to its previous spot on the screen. (some design considerations would be (1) where should the mouse go? (2) vertically up or to the apple?) Before anyone says it, I know Apple forbids a program to move the mouse. But, in this case the user is (indirectly) moving the mouse him/herself. Another consideration is: what about (command/option/shift) menu selection? One/some of these might be lost. What does everyone think about this? So this idea is attibuted to the right person... I am using a borrowed account. I am really Mike Sieweke Georgia Tech Research Institute Atlanta, Georgia Internet: sysmike@colorm.gatech.edu Bitnet: msieweke@gtri01 Usenet: ...!gatech!colorm.gatech.edu!sysmike
pv9y@vax5.CIT.CORNELL.EDU (12/01/88)
In article <6867@pyr.gatech.EDU> tynor@pyr.UUCP (Steve Tynor) writes: >Have a keyboard shortcut to move the mouse to the top of the screen. This >gives you a quick way to get at the menu bar without taking up any precious >screen real estate. Then, when you release the key(s), the mouse would >return to its previous spot on the screen. (some design considerations >would be (1) where should the mouse go? (2) vertically up or to the apple?) > >Before anyone says it, I know Apple forbids a program to move the mouse. >Mike Sieweke I'll have to check it out, but the program QuicKeys can move the mouse and might work for what you want to do. I can't remember if the mouse position returns to its previous state after executing a 'click' QuicKey. If it does work, you could define yourself a keypad of sorts, one key to take you to the apple, one to the file menu, etc. Oh, and this would work in all applications, not just the finder. I'll report on my findings in a bit. Adam
mha@batcomputer.tn.cornell.edu (Mark H. Anbinder) (12/05/88)
In article <6867@pyr.gatech.EDU> tynor@pyr.UUCP (Steve Tynor) writes: >Many of the articles I have read lately seem to be saying "It's hard to >get the mouse up to that menu bar." I have a suggestion that I'd like to >throw out for everyone to chew on: > >Have a keyboard shortcut to move the mouse to the top of the screen. > >... > > >Mike Sieweke >Georgia Tech Research Institute >Atlanta, Georgia >Internet: sysmike@colorm.gatech.edu >Bitnet: msieweke@gtri01 >Usenet: ...!gatech!colorm.gatech.edu!sysmike Or get a copy of the freeware control panel device called 'HierDA.' This cdev does several very useful things, and I find it invaluable. * Creates a submenu for each desk accessory in the DA menu that has its own menu, so that you can choose a command from the DA's own menu BEFORE opening the DA (doing so opens the DA then calls the menu item). * Brings up a full hierarchical menu bar anywhere on the desktop outside existing windows. This menu bar includes all of the menus currently at the top of the screen (it arrays them vertically, rather than horizontally), and includes all submenus. All you need to do is click on a bare part of the desktop in any program. In the Finder, you need to hold Command-Shift to do this, since you need to be able to click on the desktop in the Finder. In any other program, you can call up the menus ON TOP of windows, just by holding Command-Shift while clicking. * In the DA menu, the Control Panel is given a submenu (it doesn't normally have a menu) that consists of a list of all cdevs in the System Folder as of boot time. By choosing a cdev from this list your Control Panel opens with that cdev at the top, and open, which is MUCH better than having to search through all of your cdevs, even alphabetized, for the right one. This feature alone makes HierDA worthwhile. Definitely a program worth getting hold of. -- Mark H. Anbinder ** MHA@TCGould.tn.cornell.edu NG33 MVR Hall, Media Services Dept. ** THCY@CRNLVAX5.BITNET Cornell University H: (607) 257-7587 ******** Ithaca, NY 14853 W: (607) 255-1566 ******* Ego ipse custodies custudio
pv9y@vax5.CIT.CORNELL.EDU (12/08/88)
In article <6933@batcomputer.tn.cornell.edu> mha@tcgould.tn.cornell.edu (Mark H. Anbinder) writes: >In article <6867@pyr.gatech.EDU> tynor@pyr.UUCP (Steve Tynor) writes: >>Many of the articles I have read lately seem to be saying "It's hard to >>get the mouse up to that menu bar." I have a suggestion that I'd like to >>throw out for everyone to chew on: >> >>Have a keyboard shortcut to move the mouse to the top of the screen. >> >>... >> >> >>Mike Sieweke >>Georgia Tech Research Institute >>Atlanta, Georgia >>Internet: sysmike@colorm.gatech.edu >>Bitnet: msieweke@gtri01 >>Usenet: ...!gatech!colorm.gatech.edu!sysmike > >Or get a copy of the freeware control panel device called 'HierDA.' This >cdev does several very useful things, and I find it invaluable. Several points here. I tested QuicKeys, and unless I'm missing something, it always returns the cursor to the original spot after executing a QuicKey. The manual mentions that it does indeed do this, so I assume that it is quite possible to simply not do this in some situations, leaving the cursor wherever you want it. Shouldn't be too hard for the CE Software guys anyway. HeirDA and Versaterm 3.00 seem not to get along. In Versaterm, the normal character for the hierarchical menu is changed to another (one of several) and each DA that has a menu also has a character to the left of it. All the characters are from shifting the numbers, though I don't remember the specific ones. HierDA has worked fine with everything else (except PageMaker 3.0 which uses the same command key sequence for something). I'm using a standard SE with 1 meg, system 5.0, and some INITs which have never been a problem before, so I tend to suspect Versaterm on this one. Not a big deal, the problem is mostly cosmetic. Adam
kent@lloyd.camex.uucp (Kent Borg) (12/09/88)
In article <17508@vax5.CIT.CORNELL.EDU> pv9y@vax5.cit.cornell.edu (PUT YOUR NAME HERE) writes: ... >HeirDA and Versaterm 3.00 seem not to get along. In Versaterm, the normal >character for the hierarchical menu is changed to another (one of several) >and each DA that has a menu also has a character to the left of it. All the >characters are from shifting the numbers, though I don't remember the >specific ones. HierDA has worked fine with everything else (except PageMaker >3.0 which uses the same command key sequence for something). I'm using >a standard SE with 1 meg, system 5.0, and some INITs which have never been >a problem before, so I tend to suspect Versaterm on this one. Not a big >deal, the problem is mostly cosmetic. > HierDA .9966 and Versaterm 3.20 get along alright if you turn off the command key check box in HierDA. The problem I had was control keystrokes, which are typed with the command key in Versaterm, were being sent to desk accessories not to the serial port. I also have DiskTop, Suitcase, QuicKeys AND Tempo II, SoundMaster, SuperClock, Autoblack, Easy Access, etc. installed, so it is amazing anything works. I am astounded at how _few_ problems one has using all these system altering substances. Kent Borg kent@lloyd.uucp or hscfvax!lloyd!kent