carlton@ji.Berkeley.EDU (Mike Carlton) (07/30/87)
Thought I would throw in my 2-bits, here are my suggestions/requests for Finder improvements: I would like to model the current directory of UN*X, i.e. see only the current directory I am working on. Accordingly, opening a folder would close the current folder and open the new one. This might be accomplished by <command>-double click, for example. Going up one directory would be similar, <command>-click in the close box would close the current folder and open the parent folder. Alternatively, being able to select the whole pathname would be nice. To do this, the Finder could use a popup menu, just as standard file does. You would <command>-click on the close box (actually a new icon in the title bar would be better) and get a menu with the current path. Selecting an item would open that folder and close the current. You could even get fancy and put siblings in a sub-menu (although I admit that this could be pretty hokey). Of course, You would still be able to keep as many folders open as you wanted, but could easily reduce the clutter this way. Regards, mike (carlton@ji.berkeley.edu) Comments welcomed, flaming or not
grenley@nsc.nsc.com (George Grenley) (07/30/87)
In article <19906@ucbvax.BERKELEY.EDU> carlton@ji.Berkeley.EDU (Mike Carlton) writes: >Thought I would throw in my 2-bits, here are my suggestions/requests >for Finder improvements: > >I would like to model the current directory of UN*X, i.e. see only God, please, NO!!! As for me personally, if I wanted Unix I'd have bought it. Please, Apple, use Unix as a guide on how NOT to do things. Unix is the worst, most offensive piece of trash ever to be foisted on the unsuspecting [non- programming] public. Thanks, and remember, I know where you live... George
cds@duke.cs.duke.edu (Craig D. Singer) (07/30/87)
In article <4524@nsc.nsc.com> grenley@nsc.UUCP (George [you mean I can edit my name?] Grenley) writes: > >God, please, NO!!! As for me personally, if I wanted Unix I'd have bought it. >Please, Apple, use Unix as a guide on how NOT to do things. Unix is the worst, >most offensive piece of trash ever to be foisted on the unsuspecting [non- >programming] public. > Having had no choice but to use UselessNIX for the last six years, I'm starting to wonder why I didn't get a degree in music, or English, or anything but computers. -- Craig D. Singer ARPA: cds@cs.duke.edu Department of Computer Science UUCP: ...!decvax!duke!cds Duke University CSNET: cds@duke Durham, NC 27706-2591 USA Phone (919) 684-5110 ext. 20
olson@endor.harvard.edu (Eric Olson) (07/30/87)
In article <4524@nsc.nsc.com> grenley@nsc.UUCP (George [you mean I can edit my name?] Grenley) writes: >God, please, NO!!! As for me personally, if I wanted Unix I'd have bought it. I'm hoping to nip this in the bud. I'm not trying to initiate a flame war. And I'm trying very hard to avoid sounding like a flamer. But: The suggestions by Mike Carlton (to whom George was responding) were: 1. Command-open (Command-double click) closes frontmost window and opens subdirectory simultaneously. 2. Command-close (Command-close box) closes current window and opens (or brings frontmost) parent direntory (window). 3. Some undefined thing pops up parents and children to the frontmost (directory) window in a menu. None of these things are inherently unix-like. They are mearly conveniences, like option-close box closing all the windows (in the Finder). Because they are command key modified, they fall under the class of things on the Mac that no user ever HAS to know about. I have been wishing for a long time that the pop-up in standard file popped up with the current directory under the cursor, the ancestors above it, and the children below it (right now it's just ancestors below it). This seems easier than scrolling through a billion dimmed files to find a subdirectory. The directories could be left in the file list anyway, for backwards user-interface compatibility. >Please, Apple, use Unix as a guide on how NOT to do things. Unix is the worst >most offensive piece of trash ever to be foisted on the unsuspecting [non- >programming] public. Please, when you say things like this, keep in mind that Unix is also the best piece or trash ever to be foisted on the suspecting [programming] public. -Eric Eric K. Olson olson@endor.harvard.edu harvard!endor!olson
chris@umbc3.UMD.EDU (Chris Schanzle) (08/02/87)
> 1. Command-open (Command-double click) closes frontmost window and > opens subdirectory simultaneously. > 2. Command-close (Command-close box) closes current window and > opens (or brings frontmost) parent direntory (window). > 3. Some undefined thing pops up parents and children to the > frontmost (directory) window in a menu. > None of these things are inherently unix-like. They are mearly conveniences, > like option-close box closing all the windows (in the Finder). Because > they are command key modified, they fall under the class of things on the > Mac that no user ever HAS to know about. Now this is EXACTLY what I hate about Apple's distribution of updated software. I certainly have had a use for these features, but I have NEVER SEEN THESE DOCUMENTED. Perhaps they have been, but the existance of the documentation and how to get it isn't well known. Why doesn't Apple include a text file with updates listing all *special* command, option, shift and all the combinations with their updates? (Obviously we don't need to know the command-key equivalents since they're listed in the menus.) Things like Shift-Clicking on the print dialog box when selecting normal quality printing for bi-directional print motion. Does anybody know of a good source of this documentation? How to get it? I disagree with the above in that they fall under the class of things on the Mac that no user Has to know about. It's these damn "undocumented features" that make the Mac frustrating to use at time. Don't get me wrong, I like the Mac better than any other machine in it's price category. Oh well, enough griping...I had to get it out of my system. -- ARPA : chris@umbc3.UMD.EDU BITNET : chris@umbc "Better a bad reason than no reason at all!"
grenley@nsc.nsc.com (George Grenley) (08/03/87)
I guess I need to clarify myself a bit... In article <6798@dartvax.UUCP> earleh@dartvax.UUCP (Earle R. Horton) writes: >In article <4524@nsc.nsc.com>, grenley@nsc.nsc.com (George Grenley) writes: >... >> Please, Apple, use Unix as a guide on how NOT to do things. Unix is the worst, >> most offensive piece of trash ever to be foisted on the unsuspecting [non- >> programming] public. > >This person obviously has limited experience with MSDOS. I've had some, not a lot. The key words here, folks, are "foisted" and "non-programming". Unix was developed by serious professional programmers FOR serious professional programmers. I have watched a many non-computer people get their first exposure to computers by trying to learn unix shell and vi simultaneously, and winding up hating computers. Unix is NOT a good environment for general office automation type stuff, even though it can an is being bent that way. Every place I work some clown sticks a clapped out VT100 clone on my desk and says I get to use Unix. Oh boy. Frankly, while MSDOS lacks many things, I'd rather use Wordstar than vi, any day. Enough on this subject. Maybe Apple (or ???) should develop a 'programmer's finder'. George (my other computer is now a NSC32532)
uda@prefix.liu.se (Ulf Dahlen) (08/03/87)
In article <19906@ucbvax.BERKELEY.EDU> carlton@ji.Berkeley.EDU (Mike Carlton) writes: > >I would like to model the current directory of UN*X, i.e. see only >the current directory I am working on. Accordingly, opening a folder >would close the current folder and open the new one. This might >be accomplished by <command>-double click, for example. > If you are a real UN*X-fan, you would surely like to form your very own, specially wonderful environment. This leads me to suggest a Finder with a nice litte init-file, which would allow you to customize as much as possible. There should, for example, be possible to assign an action of some kind to any key combination. This would make you whishes come true and others as well. So, all hackers out there, give me a fsh (Finder Shell), which keep the good Mac-type interface, but allows extensive customizing. > >Regards, >mike (carlton@ji.berkeley.edu) > >Comments welcomed, flaming or not /Ulf Dahlen, Sweden uda@majestix.liu.se, uda@liuida.UUCP, u-dahlen@lisbet.liu.se
lsr@apple.UUCP (Larry Rosenstein) (08/03/87)
In article <451@umbc3.UMD.EDU> chris@umbc3.UMD.EDU (Chris Schanzle) writes: > >Now this is EXACTLY what I hate about Apple's distribution of updated >software. I certainly have had a use for these features, but I have NEVER >SEEN THESE DOCUMENTED. Perhaps they have been, but the existance of >the documentation and how to get it isn't well known. Why doesn't Apple >include a text file with updates listing all *special* command, option, >shift and all the combinations with their updates? (Obviously we don't This has been done on the last couple of releases. There is an application called TeachText that is a simple text editor with graphics. Information about the releases has been in a read-only file called README also on the disks (in the Updates folder). The problem may be that people don't get the complete set of files (perhaps because they download them from an on-line service). -- Larry Rosenstein Object Specialist Apple Computer AppleLink: Rosenstein1 UUCP: {sun, voder, nsc, mtxinu, dual}!apple!lsr CSNET: lsr@Apple.com
carlton@ji.Berkeley.EDU (Mike Carlton) (08/03/87)
Hello again: Things seem to have gone astray here. I posted my article trying to suggest possible improvements to the Finder. I would like them and hence it follows that everyone else would to :-). Unfortunately, I slipped and mentioned that dirty word UN*X. Now, I was NOT suggesting that we throw away the Finder and substitute the C shell. If someone wants that, tell them to go buy a Mac II and UN*X and get the real thing. The rest of us will stick to the Finder. What I did suggest was a couple little changes to avoid cluttering my desktop with 30 zillion windows whenever I run a program buried 30 zillion levels down. I know about option-open or whatever you call it, but that doesn't do me any good until after I've run the program. Maybe I want to look around first -- click-click "Sorry, can't open another window". In my mind these changes would reflect the current working directory idea of UN*X. Now, I like UN*X, but I understand that there might be 1 or 2 people out there that don't :-). I was trying (badly, I admit) to explain my rational, NOT to convert the Finder to csh. Whatever, can we move the ms-dos and UN*X argument to comp.ibm.kludge or comp.unix.haters or whereever? Please? Have no fear, the Mac will not give up the Finder. UN*X or ms-dos will not take over (unless you want them for YOUR personal machine -- you do have that choice now). Can we argue/suggest/criticize what the Finder X.X should look like and do? Don't bother telling me not UN*X or not ms-dos. I think we all agree on that. I vote that we need some (convenient) way to say "I want to open this folder and I don't care about its father anymore." Also, I want an easy way to say "open the father (or siblings) of this folder." Maybe I'm asking for useless stuff, if so tell me why and what I should be asking for. As to the comment about undocumented features -- exactly. What good is a text file if it is a pain to read it. Why should I have to dig out my last update disk and open README to see what 'command-option-stand on your left foot- double click' means? The Mac is suppossed to be friendly. Stuff like this can be useful (I think), but not if you don't know about it. How about something radical like a help window in the Finder explaining its shortcuts? Even the original Mac program (MacPaint) had this. cheers, mike (carlton@ji.berkeley.edu) If you have flames, let's not clutter the net, send them to /dev/null :-) If you have constructive criticism, let's hear it.
chow@batcomputer.tn.cornell.edu (Christopher Chow) (08/04/87)
[I guess its my chance to do a bit of Finder bashing... :-) ]
Well, one thing which I always wanted to see in the Finder was a way to
display text files and MacPaint type files. The Mac is the only computer
which I know of that dosen't have a fairly accessible "display this file"
type command.
Now, I realize that you can view screen files and {Mac|Full}Paint type
pictures with the Backdrop DA, but why waste a valuable DA slot for a basic
function. BTW, I think that ability to set a backdrop would be a nice thing
to do... [Servant 0.95- already does this - I hope someone would add it to
the Finder]
These little functions don't have to be full-blown. Thats why we have word
processors, text editors, paint programs, etc. All I want is the ability to
view the stuff, not edit text nor create pictures.
Finally, I think the Finder should be optimized a bit so that it can run a
bit faster. Does anyone still remember Keeper by Hertzfield? Although it
didn't work with switcher it allowed you to return to quit to the desktop in
about 1-2 seconds. Is there a reason why Apple can't get something like
that to work with the Finder, Switcher, and Juggler (opps - I mean the
nonexistant switcher-like multitasking shell)?
Christopher Chow
/---------------------------------------------------------------------------\
| Internet: chow@tcgould.tn.cornell.edu (128.84.253.35) |
| Usenet: ...{uw-beaver|ihnp4|decvax|vax135}!cornell!batcomputer!chow |
| Bitnet: chow@crnlthry.bitnet |
| Phone: 1-415-643-2953, USPS: 2299 Piedmount Av, Berkeley CA 94720 |
| Delphi: chow2 PAN: chow |
\---------------------------------------------------------------------------/striepe@muscat.UUCP (Harald Striepe) (08/04/87)
Somebody suggested for Apple to come out with an alternate finder for programmers, they did. It's called APW. -- Harald Striepe Digital Equipment Corp., SPG Mktg, Sunnyvale, CA decwrl!muscat!striepe, decwrl!dec-rhea!dec-canvas!striepe, CANVAS::STRIEPE
cgeiger@ut-ngp.UUCP (charles s. geiger, esq.) (08/05/87)
In article <4529@nsc.nsc.com>, grenley@nsc.nsc.com (George Grenley) writes: > I've had some, not a lot. The key words here, folks, are "foisted" and > "non-programming". Unix was developed by serious professional programmers > FOR serious professional programmers. I have watched a many non-computer > people get their first exposure to computers by trying to learn unix shell > and vi simultaneously, and winding up hating computers. Unix is NOT a good > environment for general office automation type stuff, even though it can an > is being bent that way. Well, my first exposure to computers _was_ trying to learn the unix shell and vi simultaneously. I thoroughly enjoyed it. An incredible learning curve, but once you get over the hump, it's really an wonderfully powerful system. cheers, from charles s. geiger ARPA: cgeiger@ngp.cc.utexas.edu cgeiger@ut-ngp.ARPA UUCP: ihnp4!ut-ngp!cgeiger allegra!ut-ngp!cgeiger gatech!ut-ngp!cgeiger seismo!ut-sally!ut-ngp!cgeiger harvard!ut-sally!ut-ngp!cgeiger
drc@dbase.UUCP (Dennis Cohen) (08/05/87)
In article <451@umbc3.UMD.EDU>, chris@umbc3.UMD.EDU (Chris Schanzle) writes: > > Now this is EXACTLY what I hate about Apple's distribution of updated > software. I certainly have had a use for these features, but I have NEVER > SEEN THESE DOCUMENTED. Perhaps they have been, but the existance of > the documentation and how to get it isn't well known. Why doesn't Apple > include a text file with updates listing all *special* command, option, > shift and all the combinations with their updates? (Obviously we don't > need to know the command-key equivalents since they're listed in the menus.) > Things like Shift-Clicking on the print dialog box when selecting normal > quality printing for bi-directional print motion. Does anybody know of a > good source of this documentation? How to get it? > But they do include this information as a Read Me file with a utility called TeachText. This has been true on the last few (3 or 4) System Update disks that I have gotten. Unfortunately, most people just get hold of a new copy of the system and finder from whereever and copy it onto their disks rather than getting the upgrade disks and using the Installer. Besides missing out on useful information, this is a STUPID thing to do with the new variety of hardware out there as the Installer updates your System properly for the HW on which you tell it you'll be running (different patches, etc.). Dennis Cohen Ashton-Tate Glendale Development Center dBASE Mac Development Team
rae@unicus.UUCP (Clith de T'nir a.k.a. Reid Ellis) (08/06/87)
Mike Carlton <carlton@ji.berkeley.edu> writes: |How about something radical like a help window in the Finder explaining |its shortcuts? Even the original Mac program (MacPaint) had this. Unfortunately, help windows would bloat the size of the Finder if they were included in every copy. My suggestion is that an optional 'Help' file exist in the system folder, and if it is there, a 'Help' button could appear in the 'About Finder...' dialog, or else a 'Help...' item could be added to the Finder's Apple menu. Alternatively, there could be a 'Help' cdev in the Control Panel (a question mark icon?). This has the advantage of not requiring any modifications to the finder and could even be done by a non-apple person. Reid Ellis, a.k.a. Clith de T'nir uunet!mnetor!unicus!rae
dlt@csun.UUCP (Dave Thompson) (08/06/87)
I think the idea of a help window in the finder (perhaps somewhat akin to
Excel's) would be a great addition. That really shouldn't add much code
to the finder as the text could be kept in a separate file. I've yet to
see a good comprehensive document on the hidden finder features.
Dave
--
Dave Thompson uucp: {ihnp4|hplabs|psivax}!csun!dlt
CSUN Computer Center phone: (818) 885-2790
18111 Nordhoff Street, Northridge, CA 91330sl@van-bc.UUCP (Stuart Lynne) (08/07/87)
In article <2606@husc6.UUCP: olson@endor.UUCP (Eric Olson) writes: :In article <4524@nsc.nsc.com> grenley@nsc.UUCP (George [you mean I can edit my name?] Grenley) writes: :>God, please, NO!!! As for me personally, if I wanted Unix I'd have bought it. :>Please, Apple, use Unix as a guide on how NOT to do things. Unix is the worst :>most offensive piece of trash ever to be foisted on the unsuspecting [non- :>programming] public. :Please, when you say things like this, keep in mind that Unix is also the :best piece or trash ever to be foisted on the suspecting [programming] public. To paraphrase Winston Churchill: Unix is the worst operating system, except for all the others. -- {ihnp4!alberta!ubc-vision,uunet}!van-bc!Stuart.Lynne Vancouver,BC,604-strphot a
maiden@sdcsvax.UCSD.EDU (VLSI Layout Project) (08/07/87)
In article <4524@nsc.nsc.com> grenley@nsc.UUCP (George Grenley) writes: >Please, Apple, use Unix as a guide on how NOT to do things. Unix is the worst >most offensive piece of trash ever to be foisted on the unsuspecting [non- >programming] public. I don't want to start a discussion on the merits/demerits of UNIX, but there are a number of good reasons to use it: 1. Many people in the academic community have reason to like UNIX and want some compatability with it. 2. It would be nice to have multi-tasking and batch processing abilities. 3. There are many utilities available, so rather than making a new OS and having a dearth of support software (which is more difficult to write on multitasking systems than on uniprocessing systems), Apple can have disk backup, archive, mail, etc. utilities already there. 4. UNIX attracts 3rd party developers. High powered software (simulation and CAD systems) are available on UNIX systems. It is relatively easy to port from a SUN UNIX to a A/UX Macintosh II. More developers will be sucked into the Mac with little effort (read: RISK) and if sales pan out, will make Mac-like versions using the A/UX toolbox. 5. UNIX is flexible. It is entirely possible to make a user friendly UNIX shell (like the finder, for example). SUNTOOLS on SUN workstations isn't too difficult to use; I'm sure somebody (e.g. APPLE) could come out with a far nicer one for end-users (SUN's is for power-users who like the flexibility of SUNTOOLS). By making A/UX and the associated toolbox, Apple gets to do all of the above. Nobody *has* to use UNIX, but many people may want to. Furthermore, there are alot of UNIX systems, and A/UX will allow a fairly transparent migration of files from one to another and a new level of networking (NFS?). EKYJ. -- Edward K.Y. Jung The Deep Thought Group: Searching for a better way to think. UUCP: {seismo|decwrl}!sdcsvax!maiden ARPA: maiden@beowulf.ucsd.edu
jong@delni.dec.com (Steve Jong/NaC Pubs) (08/08/87)
Isn't the new alert symbol (an exclamation point in a triangle) in dialog boxes a misapplication of the international icon for "WARNING"? The international icon is meant to apply to warnings of dangerous or even life-threatening hazards (electrical shock, crush hazard, etc.). Watering it down to apply to "Are you sure you want to delete the System file?" situations is bad.
jcc@ut-ngp.UUCP (j. chris cooley) (08/08/87)
In article <711@csun.UUCP>, dlt@csun.UUCP (Dave Thompson) writes: > I think the idea of a help window in the finder (perhaps somewhat akin to > Excel's) would be a great addition. That really shouldn't add much code > to the finder as the text could be kept in a separate file. I've yet to > see a good comprehensive document on the hidden finder features. > Yes! A help function is definitely needed! Then again, so is the "read text only" And one for PICT files, too. I suggest that a text file labeled HELP! (or something) be available to the user and on the distribution diskette, much like the Read Me files are today. As for incorporating that into the finder, see below. TeachText is a grand idea, Apple, but it could use some polishing. Perhaps putting it in with the finder (under "File" as "View" with "%V" (Command-V))? And add a little extra code to display PICT files, too. Like TeachText, allow no editing to keep the code simple and small. And a side note: Someone earlier suggested putting the Help feature into the Control Panel. YUCK! (if you'll excuse my frankness). First off, "Help" belongs somewhere visible or at least somewhere logical. Secondly, the control panel takes around 10 seconds to come up. By that time, A user could have already gotten out the manual. --chris Mr. "Be cool, but care"
ranson@crcge1.UUCP (D. Ranson CNET) (08/10/87)
I have some suggestions to add to the list of new features for System and
Finder:
- SFPutFile: How about a "Create Folder" button. I don't like to rely on PD
software to create a folder from an application.
- Finder: I would like real support for mini-icons: when displaying mini-
icons, the Finder should look for SICNs in the Application's bundle. Scaled
icons are awful.
Daniel Ranson.
...!seismo!mcvax!{crcge1 , cnetlu}!ransonfrankk@cwi.nl (Frank Kuiper) (08/13/87)
In article <5839@ut-ngp.UUCP> jcc@ut-ngp.UUCP (j. chris cooley) writes: >In article <711@csun.UUCP>, dlt@csun.UUCP (Dave Thompson) writes: >> I think the idea of a help window in the finder (perhaps somewhat akin to >> Excel's) would be a great addition. That really shouldn't add much code > >Yes! A help function is definitely needed! Then again, so is the "read >text only" And one for PICT files, too. I suggest that a text file Why not try to generalize this? Suppose there was a DA that could read help files. This DA could search a "Help Folder" for available files. This way, you can read the help information of any program, while working in any other program. To make things even more simpler, we could set the format for these help files as being text-only. The only feature that the Help DA would need then, is a method to search the helpfile for keywords. One would specify the keyword, and the Help DA would display the area were that keyword is used. Than the user can scroll in the window to read that part or search for something else. To avoid having to find your way in the helpfile, the first page of the Help-file should list the (unique) keywords on which the user can search. The DA is no problem. Either it already exists or one only has to add the search feature. As this DA will only be used for reading help/text files, no additional write, replace or format features have to be added. Because everyone can supply text files, anyone can make helpfiles for whatever program. Everyone can customize their own helpfiles. Anyone who is willing to tell me why this is or is not a good idee, is invited to do so. -- ___ Frank Kuiper, CWI, Amsterdam. _][__| | mcvax!frankk, frankk@cwi.nl, frankk%cwi.nl@seismo.css.gov <_______|-1 Llanfairpwllgwyngyllgogerychwyrndrobwllllantysiliogogogoch. O-O-O
akk2@ur-tut.UUCP (Atul Kacker) (08/13/87)
In article <219@dbase.UUCP> drc@dbase.UUCP (Dennis Cohen) writes: >But they do include this information as a Read Me file with a utility called >TeachText. This has been true on the last few (3 or 4) System Update disks >that I have gotten. Unfortunately, most people just get hold of a new copy >of the system and finder from whereever and copy it onto their disks rather >than getting the upgrade disks and using the Installer. Besides missing out >on useful information, this is a STUPID thing to do with the new variety of >hardware out there as the Installer updates your System properly for the HW >on which you tell it you'll be running (different patches, etc.). > >Dennis Cohen It is possible that some people miss out on stuff by not reading the READ ME file, but sometimes it is STUPID to use the Installer program (a severely brain damaged program in my opinion). Have you ever tried to use the Installer on a single drive Mac Plus ? I gave up after about 45 disk swaps, this on a computer that is user friendly ;-). I had hoped that good programming by Apple would have used the 1 Meg RAM that's in the Plus. Maybe they don't provide single disk machines to their programmers (Do CRAY's come in a single drive configuration ;-)). On a one drive machine it makes a lot more sense to just copy the System and Finder and reinstall the Fonts, DA's etc. -- ----------------------- Atul Kacker UUCP: ...seismo!rochester!ur-tut!akk2
korn@cory.Berkeley.EDU.UUCP (08/17/87)
Well, after whining a little about wanting MacWrite documents to launch
MS-Word, et. al. I did something about it. MacWrite launcher is a little
program that pretends it's MacWrite, and then turns around and Chains to
the program who's name is in resource string #128. The default is
'ms word'.
See the posting in comp.binaries.mac for more details (source too!).
Peter
--
Peter "Arrgh" Korn
korn@ucbvax.Berkeley.EDU
{decvax,dual,hplabs,sdcsvax,ulysses}!ucbvax!kornxxiaoye@eleazar.dartmouth.edu (11/15/88)
After reading people's gripes and new ideas about improving the
Macintosh finder interface. I would like to have some input as well.
All the ideas are wonderful! However, I would like to suggest some
minor improvements to the finder. "UNDO"! The "UNDO" command has been
in the Edit menu for a long time ( I don't know in which verson of
finder apple started to include it ), but even in the most recent
System Upgrade 6.0, UNDO only works with CUT/COPY/PASTE. Ahh, I think
UNDO should be more useful than this.
Please apple, let me UNDO for the following operations:
o Resizing, dragging the window
o New folder
o Dragging application(s)/file(s) from one folder to another
(regardless of the heirarchy), from desktop to another folder or vice
versa
o Dragging appl(s)/file(s) to Trash Can (before EMPTY TRASH)
All these are small things that I can UNDO them manually, however I
like a program that gives user flexibility.
It would be really nice if I can UNDO the following:
o Empty Trash
o Set Startup
o Change the memory size with Get Info
o Lock/unlock an appl/file
Am I hoping for a little too much ? Oh well, apple may even be working
on it right now, who knows !
All responses are welcome!
"VOX CLAMANTIS IN DESERTO" -- ahh, who else will I speak for !
__________________________________________________________________________
Xiaoxia Ye '91 Internet / Bitnet: xxiaoye@eleazar.dartmouth.edu
Dartmouth College Xiaoxia.Ye@dartmouth.educhangwoo@eleazar.dartmouth.edu (Chang P. Woo) (11/15/88)
In article <10895@dartvax.Dartmouth.EDU> xxiaoye@eleazar.dartmouth.edu writes: > >After reading people's gripes and new ideas about improving the >Macintosh finder interface. I would like to have some input as well. A few people have been inputing for Finder interface improvement. I think one of the biggest gripe on Finder occurs under Multifinder environment. Since Finder was made before multitasking (you can call it whatever, but for me, it IS a form of multitasking), Apple never thought carefully about the use of desktop. Here are a list of thing that I want to see in future Finder interface. (They are mainly cosmetic, and I don't think that they will be impossible to implement) 1. Window-ize the desktop. Once there are several applications opened, all the windows, disk icons and trash can are cluttered up by those windows, and you cannot see them unless you manually resize those windows. I suggest something like what MacPaint 2.0 does (tear-off menu). Within that window, we will see icons for disks and trash can icons. We can use that window just as any other windows in Finder, i.e. dragging disk and file into trash can, etc. This way, we should be able to use the screen (some of us still have 9 inch screens) little more efficiently. 2. Menu bar in application window. The latest McSink's interface and MS Window's interface (heaven forbids!) represent what I mean by. 3. A window menu in Finder (well, we can do with "Windows" DA, but I wouldn't mind if Apple officially blesses it) 4. A window with all processes running. Just like Sun 386i (or NeXT when they come out). We should have an option to collapse all the windows that belong to an application without manually closing all the work. That should clear desktop when necessary without closing all work. There must be other ways to do the above, and I am pretty sure that professionals (in Apple) can make a beautiful interface as they did with the advent of Mac. However, Apple should hurry to upgrade Mac interface to date before losing potential customers to other computers. Chang Woo ---- Chang Woo HB 2932, Dartmouth College, Hanover, NH 03755 changwoo@eleazar.dartmouth.EDU >>>>>>>>>>>> But I just happen to luuuuv reading disclaimers!
jimc@iscuva.ISCS.COM (Jim Cathey) (11/16/88)
In article <10897@dartvax.Dartmouth.EDU> changwoo@eleazar.dartmouth.edu (Chang P. Woo) writes: >>After reading people's gripes and new ideas about improving the >>Macintosh finder interface. I would like to have some input as well. >2. Menu bar in application window. The latest McSink's interface and MS >Window's interface (heaven forbids!) represent what I mean by. I disagree (somewhat) with this one. One of the big advantages of the top-of- screen menu bar is that you can be quite sloppy with the mouse and still get to the menus easily. For me, a quick flip of the wrist puts the mouse in the proper neighborhood of the menu I want, without overshooting off the top. A fine adjustment from there is very easy. I would resent having to carefully position the mouse vertically to get to every single menu I wanted. The natural width of the menus pretty much takes care of imprecise horizontal positioning, but the mouse clipping is all that saves you vertically. 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. 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? +----------------+ ! II CCCCCC ! Jim Cathey ! II SSSSCC ! ISC Systems Corp. ! II CC ! TAF-C8; Spokane, WA 99220 ! IISSSS CC ! UUCP: uunet!iscuva!jimc ! II CCCCCC ! (509) 927-5757 +----------------+ "With excitement like this, who is needing enemas?"
mfi@beach.cis.ufl.edu (Mark Interrante) (11/16/88)
Just a reminder of a long standing need for finder improvement is the trashcan. I know in the old days dumping the trash was a good idea before each appl runs, but today this is unreasonable. There should be some well defined commonsense semantics for the trashcan. ----------------------------------------------------------------------------- Mark Interrante Software Engineering Research Center mfi@beach.cis.ufl.edu CIS Department, University of Florida 32611 ----------------------------------------------------------------------------- "X is just raster-op on wheels" - Bill Joy, January 1987
mfm@bti.UUCP (Merle F. McClelland) (11/16/88)
In article <2162@iscuva.ISCS.COM> jimc@iscuva.ISCS.COM (Jim Cathey) writes: >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. > >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 >mouse pointer out of the window you're typing in or else your input will be Here here. I have a 19" display, and I use exactly the same technique of "flinging" the mouse to the top and then moving to the desired menu. Having the mouse stop at the top is an important feature, as well as always knowing where the menus are. I especially detest window environments that "grab" the pointer and don't restore it's position when finished. SunView does this with pop-up menus. If I pop-up a menu at the bottom of a window, and select an item near the bottom of the menu (one that extends below the bottom of the window), when I let go of the mouse button, the cursor remains outside of the window, not where I originally poped the menu up. Grrr. At this point I usually forget to move the pointer back inside the window, and of course my input is lost. SunView does permit setting a click-to-select mode, but it's not the default. Another suggestion for Finder/Multifinder improvements would be the ability to send a window to the back of the stack. With the Apple menu application items you can bring windows to the front (as well as simply clicking on them if they are visible), but if, for example, I have a large drawing window in the foreground, and I want to temporarily bring all other application windows to the front, I have to individually select each window. This isn't a major flaw, but I would be nice to have a complete set of window management facilities. I tend to arrange my finder windows in a tree structure, with sub folders "indented" downward and to the right, with the title bar of the child window aligned with the bottom of the parent's title bar, and to the right an equal amount. I would like to see a user-selectable layout feature that would force new finder windows to conform to a user's favorite scheme. Windows would not be constrained to this position after creation, but a finder "clean-up" option would force open windows back into the user-selected scheme. The current "Layout" utility (Public Domain) allows you select many finder attributes, and there is a window position option, but it is an absolute position, not relative to the parent window. Also, how about a Clean Up option that does an alphabetical clean up on icon windows. I believe that one of the most important features of the Mac interface is having both applications and data files, active and inactive, represented by icons. In SunView and the common XWindows environments, icons represent ONLY active processes that have been "iconified". Command execution is usually handled by custom pop-up menus or a terminal emulator command-line interface. Data file access is by typing file names. I really take advantage of the Mac's ability to have long file names, and I wouldn't like to have to type them! You can perform many file-manipulation operations (copying, moving between folders, selecting files, getting various directory listing formats, etc.) without ever touching the keyboard. In SunView/XWindows, I find that I am moving back and forth between the mouse and keyboard much more often. Finally, with Multifinder I have found that a visual equivalent to UNIX pipes would be useful for performing multiple operations on files. Perhaps a "connect-the-icons" drawing mode in the finder would permit selection of a sequence of files to execute. The one mac feature that would hinder this is the inability to select items from more than one folder at a time. I don't like cluttering my desktop with files from all over the file system in order to to perform a common operation on all of them, so the ability to select items from more than one folder would be ideal. Actually, the above description sounds more like a visual scripting scheme, which suggests another missing feature, one that Switcher had. That is, the ability to create "Sets" of applications that could be represented by an icon, and executed as a group when opened. I find that I have several groups of programs that i typically use, and this would simplify things for me. Well, I'm sure I can think of more things, but I have yet to find a better environment than the Mac for the way I like to work. That includes command-line interfaces (CP/M, MS-DOS, UNIX) or windowing environments (SunView, XWIndows, NeWS, or Microsoft Windows). No environment is perfect, but the Mac comes closest to matching how I visualize the structure of data in a file system, and I won't give it up until something MUCH better comes along. I want to thank Apple for coming up with a very good design that has been incrementally improved over the last five years, and one I expect will continue to improve. -- | "Everything you | All opinions expressed are mine, all mine! | | know | So, don't go blaming BTi for my incoherent | | is wrong!" | ramblings... | | - FST | ncr-sd!bti!mfm |
kent@lloyd.camex.uucp (Kent Borg) (11/16/88)
In article <2162@iscuva.ISCS.COM> jimc@iscuva.ISCS.COM (Jim Cathey) writes: >I disagree (somewhat) with this one. One of the big advantages of the top-of- >screen menu bar is that you can be quite sloppy with the mouse and still get >to the menus easily. For me, a quick flip of the wrist puts the mouse in the For a graphic demonstration of why menus are easier to use at the top of the screen than in the middle try the INIT that wraps the mouse around, go off the top and you arrive at the bottom. Go off the side and you arrive on the other side. Much harder to use, for me at least. I kept over shooting the menu, I depend on the fact I can slam the pointer to the top and it will be at the top. This does not mean that MultiFinder is not confusing sometimes with the changing menu bar, just that not all menus are created equal, those at the top are easier to use. (Though the pop-ups from HierDA are pretty easy...) Kent Borg kent@lloyd.uucp or hscfvax!lloyd!kent
kearns@read.columbia.edu (Steve Kearns) (11/17/88)
> >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. > What if a user had multiple screens? It seems much better to have the menus attatched to the windows in this case. -steve
changwoo@eleazar.dartmouth.edu (Chang P. Woo) (11/17/88)
In article <6018@columbia.edu> kearns@read.UUCP () writes: >> >>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. >> > >What if a user had multiple screens? It seems much better to have >the menus attatched to the windows in this case. >-steve Another problem is with screen size. In old days when everyone had 9 inch screen, software developers were careful to put everything fit into small Mac displays. That doesn't seem to be such a golden rule these days, though. Suppose you use Macromaker and On Cue under Multifinder, that fills up entire menu bar on screen. Then suppose you decide to open a DA into the application partition (such as Guidance for PageMaker help files), then you are bound to have a menu that doesn't fit into original Mac screen. I like Mac interface a lot (as someone pointed out, choosing menu item from the top of the screen is a lot easier than actually pointing out a menu from middle of the screen -- I didn't think about it when I posted the previous article), but I find myself several times to ResEdit and shorten menu names in order to make my menu bar into the screen :-( One way to solve problem is using hierachical menu, but I don't like it although I like that concept. It seems to take a little more time for me to select an item under hierachical menu (I haven't tested it, yet I feel like it). Maybe it is a price to pay in order not to clutter up the menu bar and the actual menu items. I like this discussion. Have you noticed that no one has flamed anyone else when many articles have been posted already? Chang Woo ---- Chang Woo HB 2932, Dartmouth College, Hanover, NH 03755 changwoo@eleazar.dartmouth.EDU >>>>>>>>>>>> But I just happen to luuuuv reading disclaimers!
gsbrob1@apcvxa.uchicago.edu (11/17/88)
In article <2162@iscuva.ISCS.COM>, jimc@iscuva.ISCS.COM (Jim Cathey) writes... >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? I don't like the idea of menus in windows at all, but some solution must be found for the problem of the "ever-lengthening" menu bar, and for those with multiple monitors. I hope Apple makes a leap forward and comes up with something really cool, but I don't think menus in windows is the answer. I agree that the "focus-follows-the-mouse" is really nasty; I've fooled around with it on a MicroVax and it's really awful. Robert gsbrob1@apcvxa.uchicago.edu ra_robert@gsbacd.uchicago.edu ........................... all these opinions are mine, not anyone else's ...........................
vg@csri.toronto.edu (Victor Greenberg) (11/17/88)
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.
sbb@esquire.UUCP (Stephen B. Baumgarten) (11/17/88)
In article <209@bti.UUCP> mfm@bti.UUCP (Merle F. McClelland) writes: >Another suggestion for Finder/Multifinder improvements would be the ability to >send a window to the back of the stack. With the Apple menu application items >you can bring windows to the front (as well as simply clicking on them if they >are visible), but if, for example, I have a large drawing window in the >foreground, and I want to temporarily bring all other application windows to >the front, I have to individually select each window. This isn't a major flaw, >but I would be nice to have a complete set of window management facilities. QuicKeys does this (and many other things) very nicely. And having the ``bring to front'' and ``send behind'' functions bound to keys makes them easy to use in any application. -- Steve Baumgarten | "New York... when civilization falls apart, Davis Polk & Wardwell | remember, we were way ahead of you." cmcl2!esquire!sbb | esquire!sbb@cmcl2.nyu.edu | - David Letterman
levin@bbn.com (Joel B Levin) (11/17/88)
In article <813@tank.uchicago.edu> gsbrob1@apcvxa.uchicago.edu writes:
(
(I agree that the "focus-follows-the-mouse" is really nasty; I've fooled around
(with it on a MicroVax and it's really awful.
Amen to that. It has been one of the hardest things about adapting to
the Sun in my office (I know, I could change it to require a click...)
Now when they invent "focus-follows-my-eyes" it will be perfect!
/JBL
UUCP: {backbone}!bbn!levin POTS: (617) 873-3463
INTERNET: levin@bbn.comgsbrob1@apcvxa.uchicago.edu (11/18/88)
In article <8811170216.AA22099@yorkville.csri.toronto.edu>, vg@csri.toronto.edu (Victor Greenberg) writes... [discussion] >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. I think this would be a bit tricky to do while still maintaining an intuitive user interface. In the Mac world things should be consistent: having a window respond either immediately or only after a second mouse click to mouse input, depending on whether some portion of the window was obscured, would tend to make the interface more, rather than less, complicated (at least for a great number of "average" users, I think). > >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. > This is a very good point. While I think that most modal dialog boxes do need to preempt the application to which they're related (or else they wouldn't be modal in the first place, right? :->), in the MultiFinder world it's fairly anachronistic to have them stop the whole show. At least for commonly used dialog boxes like SFGetFile and SFPutFile, as well as the "save your doc?" box, it would be good if they only stopped the application to which they were related. Robert gsbrob1@apcvxa.uchicago.edu ra_robert@gsbacd.uchicago.edu ............................................................................ . generic disclaimer: all opinions here expressed are mine and mine alone . ............................................................................
denbeste@bgsuvax.UUCP (William C. DenBesten) (11/18/88)
In article <813@tank.uchicago.edu> gsbrob1@apcvxa.uchicago.edu writes: > I agree that the "focus-follows-the-mouse" is really nasty From article <32429@bbn.COM>, by levin@bbn.com (Joel B Levin): > Now when they invent "focus-follows-my-eyes" it will be perfect! Oh wonderful. You mean that I would actually have to look at the screen while I type, as opposed to a piece of paper or another window? Focus- follows-my-intent is even harder. The mistake, as I see it is that clicking in a window makes it the active window and brings it to the front, even if all I wanted to do was scroll the contents. The system is not really able to distinguish between three seperate actions on inactive windows: o I want to activate a window, so it gets keystrokes and menu bar control. o I want to use a control in a window. o I want to change the layering of a window. I should not have to change all three things simultaneously. -- William C. DenBesten denbeste@bgsu.edu
DN5@PSUVM.BITNET (11/18/88)
How about this for a menu idea:
Keep the menubar at the top of the screen, but also have a way to access the
menu from a window (perhaps by double-clicking on the name of the window).
The menu at the top of the screen will always show the choices available, and
still be useful for those who like it (I do right now, but if I get a bigger
screen...).
The menu associated with each window (the same menu for each window in a
given application) I imagine as a pop-up heirarchical menu.
This does not seem to be a difficult addition to the interface, nor do I
see any major programming difficulties (except for all of the custom WDEFs
out there...).
Just my 2 cents.
Jay, etc...goldman@Apple.COM (Phil Goldman) (11/18/88)
In article <209@bti.UUCP> mfm@bti.UUCP (Merle F. McClelland) writes: >... >one that Switcher had. That is, the ability to create "Sets" of applications >that could be represented by an icon, and executed as a group when opened. I >find that I have several groups of programs that i typically use, and this would >simplify things for me. Future Finders will probably provide explicit support for working sets. However, there is an easy way to create them right now. Simply create a startup set by using the "Set Startup..." menu item in the Finder. Then, look for the file called "Finder Startup" in the system folder. Put it wherever you want and rename it whatever you want. Any time you double- click on it it will start up all of the appropriate apps and DAs. -Phil Goldman Apple Computer
mfm@bti.UUCP (Merle F. McClelland) (11/18/88)
In article <236@internal.Apple.COM> goldman@Apple.COM (Phil Goldman) writes: >Future Finders will probably provide explicit support for working sets. >However, there is an easy way to create them right now. Simply create >a startup set by using the "Set Startup..." menu item in the Finder. Then, >look for the file called "Finder Startup" in the system folder. Put it >wherever you want and rename it whatever you want. Any time you double- >click on it it will start up all of the appropriate apps and DAs. > >-Phil Goldman >Apple Computer Thanks for the info, I'll have to try this. -- | "Everything you | All opinions expressed are mine, all mine! | | know | So, don't go blaming BTi for my incoherent | | is wrong!" | ramblings... | | - FST | ncr-sd!bti!mfm |
mouser@Portia.Stanford.EDU (Michael Wang) (11/20/88)
In all this discussion of where to put menus (in a fixed menu bar, in the document's window, etc.), nobody's mentioned a simple hardware solution... (Excuse me for a second while a climb into my flame-proof suit) ...a two-button mouse! If one button is dedicated to bringing up a pop-up, hierarchical menu and selecting from it (similar to what most workstation mice and PopIt do), accessing menus on large screens would be a lot easier. I already use PopIt in conjunction with Stepping Out II, but I dislike having to hold down Shift-Command everytime I want the menus to pop-up. I don't think it would be too hard to develop a two-button mouse with the associated driver/CDEV for the ADB port. Now, I know people are going to say that two-button mice are harder to learn, but if the only function of the second button is to bring up the pop-up menu, it shouldn't be too hard to learn. Then of course somebody will ask, "which button do you use to select a menu from the regular menu bar..." (Boy, it's hot inside this suit, better take it off now...) BTW, if you want an example of a modeless Open dialog box, take a look a QUED/M, it has a very nice one. -Michael Wang +--------------+------------------------------------------------------------+ | Michael Wang | Stanford University, Stanford, CA 94305 | |--------------+------------------------------------------------------------| | ARPAnet, CSNET, BITNET, Internet: mouser@portia.stanford.edu | | UUCP: ...decwrl!portia.stanford.edu!mouser AppleLink: ST0064 | +---------------------------------------------------------------------------+
gsbrob1@apcvxa.uchicago.edu (11/21/88)
In article <4174@Portia.Stanford.EDU>, mouser@Portia.Stanford.EDU (Michael Wang) writes... >In all this discussion of where to put menus (in a fixed menu bar, in the >document's window, etc.), nobody's mentioned a simple hardware solution... > >(Excuse me for a second while a climb into my flame-proof suit) > >....a two-button mouse! If one button is dedicated to bringing up a pop-up, >hierarchical menu and selecting from it (similar to what most workstation >mice and PopIt do), accessing menus on large screens would be a lot easier. >I already use PopIt in conjunction with Stepping Out II, but I dislike >having to hold down Shift-Command everytime I want the menus to pop-up. I >don't think it would be too hard to develop a two-button mouse with the >associated driver/CDEV for the ADB port. Now, I know people are going to >say that two-button mice are harder to learn, but if the only function of >the second button is to bring up the pop-up menu, it shouldn't be too hard >to learn. Then of course somebody will ask, "which button do you use to >select a menu from the regular menu bar..." > Well, no flame here, but I disagree with the concept. I don't think pop-up menus for main menus is a good idea: one of the nice things about the Mac is being able to see the main menu all the time. In addition, on most of the workstations that I've used the menu you get is dependent on _where_ the cursor is at the time. Now this may be what you'd like, since it makes mouse travel less, but I would say it's not as intuitive to the average user as the current setup (nor is the 2 button mouse). Remember, the whole point of this is to make a consistent and simpler interface for _all_ users, not just the "power" user. I think the basic Mac concept is a good one, but is -- as those participating in this discussion are saying -- in need of refinement. I don't think a 2-button mouse is the way to go. Robert gsbrob1@apcvxa.uchicago.edu ra_robert@gsbacd.uchicago.edu ............................................................................ . generic disclaimer: all opinions here expressed are mine and mine alone . ............................................................................ I think pop-up menus for subsidiary menus are OK, but their use should be carefully considered.
sbb@esquire.UUCP (Stephen B. Baumgarten) (11/21/88)
In article <61982DN5@PSUVM> DN5@PSUVM.BITNET writes: >How about this for a menu idea: > >Keep the menubar at the top of the screen, but also have a way to access the >menu from a window (perhaps by double-clicking on the name of the window). > >The menu at the top of the screen will always show the choices available, and >still be useful for those who like it (I do right now, but if I get a bigger >screen...). > >The menu associated with each window (the same menu for each window in a >given application) I imagine as a pop-up heirarchical menu. I like this idea too, and in fact McSink 6.1 does a very nice job of implementing it. It even scrolls the menu horizontally if it doesn't fit. Of course, this makes the Mac interface more like Microsoft Windows, something I doubt anyone at Apple is eager to do. -- Steve Baumgarten | "New York... when civilization falls apart, Davis Polk & Wardwell | remember, we were way ahead of you." cmcl2!esquire!sbb | esquire!sbb@cmcl2.nyu.edu | - David Letterman
sho@pur-phy (Sho Kuwamoto) (11/21/88)
Does everybody like the velocity dependent mouse? Sometimes I like it, and sometimes it annoys me. When we didn't have it, I wished we did. Now, I'll flick the mouse over a good long ways for something, and when I try to go back to the original point more slowly for whatever reason, I run out of room. (obviously) Not a big deal, I guess. I would go for a two button mouse, although I still think a one button mouse is still easier to use. On a related note, why is there no doubleClickEvt? Applications that don't use double clicks could disable the event, and a double click would be interepereted as two single clicks. -Sho
roland@polya.Stanford.EDU (Roland Conybeare) (11/22/88)
How about putting the trashcan, disks etc. in their own window/palette? Then you could bring them to the front easily, and send other windows behind them. I think this would be a good solution because it makes it easy to access the finder icons when you need them. Note that switching to finder would bring this palette to the front. Roland Conybeare (roland@polya.stanford.edu)
kent@lloyd.camex.uucp (Kent Borg) (11/23/88)
In article <1665@pur-phy> sho@newton.physics.purdue.edu.UUCP (Sho Kuwamoto) writes: >Does everybody like the velocity dependent mouse? I do. It is amazingly powerful, use Sunview for a while if you want to be sure. I think it is a very important part of what makes the Macintosh so good. >I would go for a two button mouse, although I still think a one button >mouse is still easier to use. Though I think 2 or 3 buttons are far too many, if a manufacturer insists on having more than one button on a mouse, I think it very important that they not be distinguished only by left/right (shame on you nExt!), new Microsoft mice are better than the old in this respect. Far too many normal people get left and right confused--just imagine how dislexics feel. (Actually, I suspect that left handed dislexics were among the first to embrace the Mac. How many others of you are out there??) > On a related note, why is there no >doubleClickEvt? Applications that don't use double clicks could disable >the event, and a double click would be interepereted as two single clicks. > >-Sho A very good reason. A double click takes time. If every single click had to wait long enough to be sure it was not part of a double click before it could be reported, the Macintosh would be very sluglish. A single click is part of a double click. Double clicks should be additions to single clicks so that when the first click comes by it can be treated like a single click and when the second click arrives the application extends the single click to whatever the application's specific idea of what a double click is. Kent Borg kent@lloyd.uucp or hscfvax!lloyd!kent
@DOUGHNUT.CS.ROCHESTER.EDU:miller@CS.ROCHESTER.EDU (11/24/88)
From: Brad Miller <miller@CS.ROCHESTER.EDU>
Date: 23 Nov 88 01:52:32 GMT
From: kent@lloyd.camex.uucp (Kent Borg)
Though I think 2 or 3 buttons are far too many, if a manufacturer
insists on having more than one button on a mouse, I think it very
important that they not be distinguished only by left/right (shame on
you nExt!), new Microsoft mice are better than the old in this
respect. Far too many normal people get left and right confused--just
imagine how dislexics feel.
I've been using a 3 button mouse on my Symbolics for years. No-one at our
site has ever complained about it -- they only complained about the old
Xerox two button mouse as not being enough buttons.
5 buttons anyone? (thumb can be a shift key)..
One thing the Symbolics/Explorer lets you do is use shifty keys with the
mouse, so shift-left is equivalent to double-click left. You can then
disable double click entirely and just use shift. Of course, you still have
control, meta, super, hyper, and symbol to put additional combinations on
the mouse.
A pity when apple redesigned their keyboard they a) didn't include more
shift keys and b) decided on such a lousy key arrangement. Control is used
almost as often as shift in a real editor (that is, EMACS or derivatives)
and should be as easy to hit as shift is. All shift keys should be
duplicated on both sides of the spacebar for touch typing as well...
----
Brad Miller U. Rochester Comp Sci Dept.
miller@cs.rochester.edu {...allegra!rochester!miller}mce@tc.fluke.COM (Brian McElhinney) (11/24/88)
In article <848@tank.uchicago.edu> gsbrob1@apcvxa.uchicago.edu writes: > I don't think pop-up menus for main menus is a good idea: one of the nice > things about the Mac is being able to see the main menu all the time. [...] > Remember, the whole point of this is to make a consistent and simpler > interface for _all_ users, not just the "power" user. Yes, it should be easy, consistent and simple, but that doesn't mean you can't have pop-up menus or three-button mice. Why not have both? Main menus and pop-up menus. One button or multi-button mice. I would happily pay for a mouse with shift-click and command-click buttons. Confusing? Make them smaller and label them. It would be a real benefit to those people that *use* shift- and command-click, and would require only that novices learn to use the big, friendly, button (labeled 'push me' :-). Brian McElhinney mce@tc.fluke.com
warner@s3snorkel.ARPA (Ken Warner) (11/25/88)
In article <264@lloyd.camex.uucp> kent@lloyd.UUCP (Kent Borg) writes: >In article <1665@pur-phy> sho@newton.physics.purdue.edu.UUCP (Sho Kuwamoto) writes: >>I would go for a two button mouse, although I still think a one button >>mouse is still easier to use. > >Though I think 2 or 3 buttons are far too many, ... Unless you are using X Windows or Smalltalk-80, both of which are going to be more and more important to all of us. Now, when talking small, I have to use both arms to push the middle and right buttons. That is, I have to push the Command key and click the mouse to simulate pushing the right button on a three-button mouse. This is a pain. Smalltalk-80 was designed around a three-button mouse. I see a product nitch. Ken Warner
holland@m2.csc.ti.com (Fred Hollander) (11/26/88)
In article <1988Nov23.153852.17569@cs.rochester.edu> @DOUGHNUT.CS.ROCHESTER.EDU:miller@CS.ROCHESTER.EDU writes: >From: Brad Miller <miller@CS.ROCHESTER.EDU> > >One thing the Symbolics/Explorer lets you do is use shifty keys with the > >A pity when apple redesigned their keyboard they a) didn't include more >shift keys and b) decided on such a lousy key arrangement. Control is used >almost as often as shift in a real editor (that is, EMACS or derivatives) >and should be as easy to hit as shift is. All shift keys should be >duplicated on both sides of the spacebar for touch typing as well... If you're used to a Lisp Machine, as I am, you should at least appreciate that Apple did duplicate "super/meta/control" keys on both sides of the space bar. Although I had to modify the KMAP resource and swap key caps to put them in the right order: command/option/control-space-control/option/command. You're right about the frequent use of the control key and I'm thankful that I can now conveniently reach it with my thumb while the rest of my fingers type. Now, if I could only use the caps lock key for rubout... Fred Hollander Computer Science Center Texas Instruments, Inc. holland%ti-csl@csnet-rela The above statements are my own and not representative of Texas Instruments.
mfi@beach.cis.ufl.edu (Mark Interrante) (11/27/88)
Why doesnt apple make the "hidden" feature of double clicking on the grab area of a window to get the parent window "unhidden"? I have to use the program DESKTOP to configure the system! This does not sound like a confusing feature that should be hidden from naive users. ----------------------------------------------------------------------------- Mark Interrante Software Engineering Research Center mfi@beach.cis.ufl.edu CIS Department, University of Florida 32611 ----------------------------------------------------------------------------- "Imagine what it would be like if TV actually were good. It would be the end of everything we know." Marvin Minsky
czychi@ethz.UUCP (Gary Czychi) (11/28/88)
Hi there everybody,
what I would like to see much more would be a small enhancement of the DA
Handler.
Nearly *every* application (even those from Microsoft) have their command-W
and their command-Q for close/quit. Why doesn't the DA Handler takes
advantage of the *Apple* user interface??
...just a question... :-)
Gary
Gary T. Czychi University of St.Gallen, Switzerland
CZYCHI@CSGHSG52.BITNET (also: CSGHSG53)
CZYCHI@ETHZ.UUCP
Tel.: --41 / 71 / 28 30 55stuartb@microsoft.UUCP (Stuart Burden) (11/28/88)
In article <5215@polya.Stanford.EDU> czychi@bernina.UUCP (Gary Czychi) writes: | what I would like to see much more would be a small | enhancement of the DA Handler. Nearly *every* application | (even those from Microsoft) have their command-W and their | command-Q for close/quit. Why doesn't the DA Handler takes | advantage of the *Apple* user interface?? It would seem logical to me, that none of these command keys would apply to DA Handler. Thus leaving those keys available to be implemented by the DA itself, as a Quit or Window close command. While it seems a little strange to "Quit" a DA rather than close it, under MultiFinder this is not so strange, as you are running under a seperate application layer (DA Handler), and thus makes it logical to quit the "application" which is basically what the DA has become. What I'm curious about is the way DA's close themselves. Most DA's will quit the DA Handler, but some do not. It would seem that most "well behaved" DA's should also close the DA Handler, that way you really don't need to have a quit command key for DA Handler cos it will disappear when the DA itself is closed or quit from. Perhaps someone might shed some light on the standard closing practice of DA's and how this effects (should effect) the DA Handler. | ...just a question... :-) | Gary Stu. __Paths to my door:______________________ stuartb@microsof.beaver.cs.washington.edu stuartb%microsof@uw-beaver.arpa stuartb@microsof.uucp _________________________________________ Usual disclaimer, that all the above is pure fantasy and Microsoft only gave me the Mountain Dew to dream it all in a caffeine haze :-{) :-{) _______________________________________________________________________