ac08@vaxb.acs.unt.edu ((C. Irby)) (07/05/90)
In article <886@mdavcr.UUCP>, ewm@mdavcr.UUCP (Eric W. Mitchel) writes: > In article <1990Jul3.143206.940@acc.stolaf.edu> sobiloff@agnes.acc.stolaf.edu (Chrome Cboy) writes: >>>I'm more used to Windows >>>(although I'm typing this between crashes on a IIfx) and find many aspects >>>of the Mac interface different, confusing, and at times limited. >> >>How so (esp. limited)? > > I am a big Mac fan, but I am realistic enough to recognize the > deficiencies as well as the stregths of the Mac. Among the limitations: > > - No standard command line interface. A BIG minus for many power > users. Try deleting a number of files in nested directories that > satisfy some search criterion with a single command. A real "power user" organizes his or her files a little better than that. Of course, all of the real Mac powerheads are gonna get A/UX anyway- so who really cares? I work on Macs all of the time, and might have saved nearly a minute in the last three months with something like this... :) <P.S.- Whatinhell is a "standard" CLI? No two the same, dude- look at "directory." Dir, ls, or directory? > Try opening > the directory window on your hard disk when the screen is filled > with a Word4 window (without moving/resizing the Word window). > Lets be realistic - the Mac interface is among the best, but has > many flaws too. In Multifinder, I just grab the mouse and click in the upper right corner of the screen on the little icon until the Finder comes up... What? You didn't know you could do that? It's in the manual... But given a choice, I'll just open DiskTop and do my directory work in it... "Real" DAs are great- you should learn to use them. All of the imitations done by the other OSs are too kludgy to be useful. > > Eric > > =========================================================================== > Disclaimer: If I could get anybody else to accept responsibility for > my opinions, I would. -- \ C Irby \ "The following will be a test of the ac08@vaxb.acs.unt.edu \ Emergency .Signature System. ac08@untvax \ This is only a test. \ Beeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeep." \
strobl@gmdzi.UUCP (Wolfgang Strobl) (07/05/90)
ac08@vaxb.acs.unt.edu ((C. Irby)) writes: >A real "power user" organizes his or her files a little better than that. This assumes that there is just one "right" way to organize the files into a tree or into a sequence. >.... >But given a choice, I'll just open DiskTop and do my directory work in it... >"Real" DAs are great- you should learn to use them. >All of the imitations done by the other OSs are too kludgy to be useful. If a GUI has been designed for multiple applications running concurrently and sharing a screen space, there is no need for kludges like DAs or Multifinders. Wolfgang Strobl #include <std.disclaimer.h>
russotto@eng.umd.edu (Matthew T. Russotto) (07/05/90)
>>But given a choice, I'll just open DiskTop and do my directory work in it... >>"Real" DAs are great- you should learn to use them. >>All of the imitations done by the other OSs are too kludgy to be useful. > >If a GUI has been designed for multiple applications running concurrently >and sharing a screen space, there is no need for kludges like DAs or >Multifinders. Internally, DAs and Multifinder are a kludge. But externally, I don't see how either is a kludge. -- Matthew T. Russotto russotto@eng.umd.edu russotto@wam.umd.edu ][, ][+, ///, ///+, //e, //c, IIGS, //c+ --- Any questions? Hey! Bush has NO LIPS!
strobl@gmdzi.UUCP (Wolfgang Strobl) (07/06/90)
russotto@eng.umd.edu (Matthew T. Russotto) writes: >Internally, DAs and Multifinder are a kludge. But externally, I don't see >how either is a kludge. I hear similar statements when I argue with GEM fans about why I prefer Windows over GEM. GEM looks much more like the Mac than Windows does, but is - as far as I can tell - nowhere object oriented or message passing based internally. It shares with the Mac the initial single tasking design, which make things like DAs and Multifinder necessary. Windows has (and needs) neither. Wolfgang Strobl #include <std.disclaimer.hpp>
ngg@bridge2.ESD.3Com.COM (Norman Goodger) (07/07/90)
In article <3039@gmdzi.UUCP> strobl@gmdzi.UUCP (Wolfgang Strobl) writes: > >If a GUI has been designed for multiple applications running concurrently >and sharing a screen space, there is no need for kludges like DAs or >Multifinders. >Wolfgang Strobl This above statement shows severe ignorance of how the Mac works. Multifinder is how the Mac does its multiprocessing. DA's are just small applications that run as another process just as other applications do. Yes there are differences between DA's and applications, but as 7.0 and beyond comes out, the difference fades.. -- Norm Goodger SysOp - MacInfo BBS @415-795-8862 3Com Corp. Co-SysOp FreeSoft RT - GEnie. Enterprise Systems Division (I disclaim anything and everything) UUCP: {3comvax,auspex,sun}!bridge2!ngg Internet: ngg@bridge2.ESD.3Com.COM
lars@spectrum.CMC.COM (Lars Poulsen) (07/09/90)
In article <886@mdavcr.UUCP>, ewm@mdavcr.UUCP (Eric W. Mitchel) writes: >> Try opening >> the directory window on your hard disk when the screen is filled >> with a Word4 window (without moving/resizing the Word window). >> Lets be realistic - the Mac interface is among the best, but has >> many flaws too. In article <28778.269229da@vaxb.acs.unt.edu> ac08@vaxb.acs.unt.edu ((C. Irby)) writes: >In Multifinder, I just grab the mouse and click in the upper right corner of >the screen on the little icon until the Finder comes up... >What? You didn't know you could do that? It's in the manual... > >But given a choice, I'll just open DiskTop and do my directory work in it... >"Real" DAs are great- you should learn to use them. I don't think you understood the problem. The problem is that the Icons on the desktop (disks, "most-frequently-used" applications, thrash can ...) are not in the same display layer as the Finder windows, but hidden under all the windows. So when you're in Word (or Kermit, or any other application that uses full-screen windows and does not block the desk top layers as Hypercard does) you cannot get to the thrash can. This can be really annoying. Saying that there are 3rd-party kluges to make up for such a deficiency is not relevant. -- / Lars Poulsen, SMTS Software Engineer CMC Rockwell lars@CMC.COM
lars@spectrum.CMC.COM (Lars Poulsen) (07/09/90)
In article <886@mdavcr.UUCP>, ewm@mdavcr.UUCP (Eric W. Mitchel) writes: >> I am a big Mac fan, but I am realistic enough to recognize the >> deficiencies as well as the stregths of the Mac. Among the limitations: >> - No standard command line interface. A BIG minus for many power >> users. Try deleting a number of files in nested directories that >> satisfy some search criterion with a single command. In article <28778.269229da@vaxb.acs.unt.edu> ac08@vaxb.acs.unt.edu ((C. Irby)) writes: >A real "power user" organizes his or her files a little better than that. Absent the (coming) alias feature, the system right out of the box does not have a good way to organize files. I want to have my most frequently used data files grouped in one place for easy reference; I also want all files related to a particular application/system in one place. Yes, Disktop, Powerstation etc will do that. But we were discussing the system as provided by the vendor. >Of course, all of the real Mac powerheads are gonna get A/UX anyway- >so who really cares? I work on Macs all of the time, and might have >saved nearly a minute in the last three months with something >like this... :) I see... and "real programmers" use SUNs, so who cares what a Mac looks like :-) :-) ><P.S.- Whatinhell is a "standard" CLI? No two the same, dude- look at >"directory." Dir, ls, or directory? But all the modern CLIs allow user tailoring; so when I move back and forth between VMS and Unix, I have aliases for all the common commands. The actual command set is much less important than having a command line interface. My Mac at home has its own phone line. Many times I have wished that I could call it from work and Kermit a file. MPW is a great command line interface; but even SYMANTEC does not use it, so it's obviously not "standard". If I could run Think C under MPW, I'd buy MPW. -- / Lars Poulsen, SMTS Software Engineer CMC Rockwell lars@CMC.COM
kenk@tellabs.com (Ken Konecki) (07/10/90)
In article <1990Jul8.214605.24056@spectrum.CMC.COM> lars@spectrum.CMC.COM (Lars Poulsen) writes: >on the desktop (disks, "most-frequently-used" applications, thrash can >...) are not in the same display layer as the Finder windows, but hidden >under all the windows. So when you're in Word (or Kermit, or any other >application that uses full-screen windows and does not block the desk >top layers as Hypercard does) you cannot get to the thrash can. This can >be really annoying. The answer is to shrink your windows (if possible) so that you can click on the icons at anytime without having to click on the small icon in the menu bar (or select finder from the apple menu) to bring up the finder. What an application should do is to shrink its window when its switched out, so that the finder icons (Trash can and disks) are not covered when the application is not active. I know that Versaterm Pro does this and I think its a really nice thing to do. Cheers, -Ken K -- Ken Konecki "Eat well, stay fit, and die anyway" e-mail:kenk@tellabs.com -or- ...!uunet!tellab5!kenk U.S. Mail: 1271 Portchester Circle, Carol Stream, IL 60188
kenk@tellabs.com (Ken Konecki) (07/10/90)
In article <1990Jul8.220052.24143@spectrum.CMC.COM> lars@spectrum.CMC.COM (Lars Poulsen) writes: >>> - No standard command line interface. A BIG minus for many power >>> users. Try deleting a number of files in nested directories that >>> satisfy some search criterion with a single command. > >In article <28778.269229da@vaxb.acs.unt.edu> > ac08@vaxb.acs.unt.edu ((C. Irby)) writes: >>A real "power user" organizes his or her files a little better than that. Power users, shmower users. There's no such thing as a power user. People who use computers are users, plain and simple. Period. End of story. I don't know where the term came from, but it's the stupidest phrase I have ever heard. Can anybody even define what a power user is (as opposed to a powerless user?). As for deleting a number of files in nested directories, no CLI (command line interface) I have ever used can do this. All the ones I have seen must invoke another program to accomplish it (e.g. the Unix shells would call the find command). And, with few exceptions, a CLI is only as good as the programs it invokes. Cheers, -Ken K -- Ken Konecki "Eat well, stay fit, and die anyway" e-mail:kenk@tellabs.com -or- ...!uunet!tellab5!kenk U.S. Mail: 1271 Portchester Circle, Carol Stream, IL 60188
jmpiazza@sybil.cs.Buffalo.EDU (Joseph M. Piazza) (07/11/90)
In article <2715@bridge2.ESD.3Com.COM> ngg@bridge2.ESD.3Com.COM (Norman Goodger) writes: >In article <3039@gmdzi.UUCP> strobl@gmdzi.UUCP (Wolfgang Strobl) writes: >> >>If a GUI has been designed for multiple applications running concurrently >>and sharing a screen space, there is no need for kludges like DAs or >>Multifinders. >>Wolfgang Strobl > >This above statement shows severe ignorance of how the Mac works. Them's strong words you're using. >Multifinder >is how the Mac does its multiprocessing. DA's are just small applications >that run as another process just as other applications do. I think what Mr. Strobl was referring to the fact that the Finder was not originally designed to multitask -- not even cooperative multitasking. While "kludge" may be an exageration, Multifinder is a revision of the the same non-multitasking Finder. In this light I can't see how you can justify calling him ignorant. Neither God nor Apple created the Mac in one day (though there are rumors that Apple was present in the garden of Eden when Man and Women were created :-) as was IBM in the guise of a serpent). :-) >... Yes there are >differences between DA's and applications, but as 7.0 and beyond comes >out, the difference fades.. Just as your memories of the pre-Multifinder era have faded. Flip side, joe piazza --- In capitalism, man exploits man. In communism, it's the other way around. CS Dept. SUNY at Buffalo 14260 UUCP: ...!{watmath,boulder,decvax,rutgers}!sunybcs!jmpiazza BITNET: jmpiazza@sunybcs.BITNET Internet: jmpiazza@cs.buffalo.edu >Norm Goodger {3comvax,auspex,sun}!bridge2!ngg ngg@bridge2.ESD.3Com.COM
francis@giza.cis.ohio-state.edu (RD Francis) (07/11/90)
Joe Piazza writes: <In article <2715@bridge2.ESD.3Com.COM> ngg@bridge2.ESD.3Com.COM (Norman Goodger) writes: <>Multifinder <>is how the Mac does its multiprocessing. DA's are just small applications <>that run as another process just as other applications do. < I think what Mr. Strobl was referring to the fact that the <Finder was not originally designed to multitask -- not even cooperative <multitasking. While "kludge" may be an exageration, Multifinder is a <revision of the the same non-multitasking Finder. < joe piazza <CS Dept. SUNY at Buffalo 14260 <UUCP: ...!{watmath,boulder,decvax,rutgers}!sunybcs!jmpiazza <BITNET: jmpiazza@sunybcs.BITNET Internet: jmpiazza@cs.buffalo.edu It is perhaps important to note that the Finder is even now not designed to multi-task, per se. Multi-tasking is handled by the System; the Finder is simply a program that is used to manipulate files and access other applications. Multi-Finder, as most Mac people know, is something of a misnomer. As far as I am aware, the Multi-Finder is simply a chunk of code that the system uses to do multi-tasking. It is, of course, true that this code was added to the Mac a few years after it came out. However, I do not know if it was necessary to make any significant changes to the Finder in order for it to work with Multi-Finder. This is, perhaps, a point of interest in this discussion; the fact that, despite Multi-Finder's status as a major change in how things in the Mac world worked, the fact that a large number of programs worked with Multi-Finder with no more than some minor changes. Even some programs that state that they don't work with Multi-Finder can be used (admittedly, with caution). -- R David Francis francis@cis.ohio-state.edu
minich@d.cs.okstate.edu (Robert Minich) (07/11/90)
by jmpiazza@sybil.cs.Buffalo.EDU (Joseph M. Piazza): |>>If a GUI has been designed for multiple applications running concurrently |>>and sharing a screen space, there is no need for kludges like DAs or |>>Multifinders. |>>Wolfgang Strobl Don't confuse Multifinder with Finder. (How could that possibly happen? :-) The Finder is just a program, although it is massively hooked to the OS like no other program has a right to be. MultiFinder is the set of extensions to the OS that provide the cooperative multitasking. |>Multifinder |>is how the Mac does its multiprocessing. DA's are just small applications |>that run as another process just as other applications do. DA's are not just small applications. They are much more restricted than that. They are symbiotic, single chunks of code designed to work with a host. With System 7, writing DA's will become rather stupid. They'll look like an app to the user, but they are still restricted. DA's have a weird convention for communicating with the host that is a pain. I'd rather just write a real program and have the benefits of multiple CODE segments, more than one menu, etc. | I think what Mr. Strobl was referring to the fact that the | Finder was not originally designed to multitask -- not even cooperative | multitasking. While "kludge" may be an exageration, Multifinder is a | revision of the the same non-multitasking Finder. See the above contrast of MultiFinder and the Finder. Kludge could probably be pinned to MultiFinder, but definitely not the Finder. I believe that in Sys 7, there will be the addition of a "Desktop" layer which will be the parent of all disk voulmes. (This will also show up in the stnadard file DLOG box, allowing you to see the volumes in a similar manner to folders.) Also, Finder 7 will have a "Set aside..." option to allow you to hide the windows of other running applications. (Currently, I have an FKEY [a really small piece of code that is invoked by typing cmd-shft-#, where # is 0-9] that zaps the content region of the current window, letting you see what is behind it. This really is useful with a term program that covers the entire screen, even during downloads. I just zap it and the only thing that remains is the title bar and a one pixel outline of the windows edge!) -- | _ /| | Robert Minich |Q: Why is the food so lousy, and | \'o.O' | Oklahoma State University |the service so bad? Time traveler: | =(___)= | minich@d.cs.okstate.edu |A:The waiters know in advance what | U | - Bill sez "Ackphtth" |kind of tip they'll be getting.
ewm@mdavcr.UUCP (Eric W. Mitchel) (07/12/90)
In article <2977@tellab5.tellabs.com> kenk@tellabs.com (Ken Konecki) writes: > >Power users, shmower users. There's no such thing as a power user. >People who use computers are users, plain and simple. Period. End of >story. I don't know where the term came from, but it's the stupidest >phrase I have ever heard. Can anybody even define what a power user is (as >opposed to a powerless user?). It seems pretty obvious what most people mean when they use the term "power user". Are you saying that everyone uses the same level of functionality of a computer? Funny, last time I talked to my secretary she had no idea what a UNIX pipe was or what 'sccs' was for. If you have to ask what a power user is, then you obviously aren't one. If you just have a problem with the wording of the phrase, think of a better one. >As for deleting a number of files in nested directories, no CLI >(command line interface) I have ever used can do this. All the ones I >have seen must invoke another program to accomplish it (e.g. the Unix >shells would call the find command). And, with few exceptions, a CLI is >only as good as the programs it invokes. > >Cheers, > -Ken K This begs the point. At least with a CLI you CAN easily invoke programs to do things like deleting files in nested directories. I find one of the greatest pains of the Mac OS is the difficulty of executing small utility programs. One generally has the choice of a) dragging everything you ever use to the desktop b) finding a third party utility that allows easier access to files c) clicking through nested levels of folders What a drag ;-). Through my UNIX CLI, I can set paths to various directores, then invoke programs by name, without specifying their exact location. This permits me to sort my directories logically and still have simple access to programs. Another problem is that CLI invoked programs can be made much simpler than the typical MAC application, since there is no nead to support a user interface. In UNIX, parameters can be passed to the program by typing them on the same CLI line when invoking the program. Very handy if you need to execute some utility program (like "find", "grep", "more", etc) quickly. On the Mac, one has to invoke the program, then wait for some user interface (ie: dialog box) to come up, then enter the parameters in the correct place, etc. This means greater user overhead, greater programmer overhead, and greater CPU overhead. This leads to yet another deficiency - the lack of a CLI scripting language. While the Mac now has a number of Macro utitlities available, they are a poor substitute. (At least the ones I've seen - If you can suggest a good one, TELL ME, PLEASE). One of the great things about UNIX is the ability to take a bunch of small utility programs and assemble them in a CLI script to perform some operation that you need. I use this all the time (power user?). Of course, one of the reasons why UNIX CLI programs and scripts are so useful is the ability to use UNIX pipes. But that is another issue. Anyway, to restate my original posting, I am a big Mac fan, but I find it constantly amazing how blind a lot of Mac "patriots" are. It is like the kind of mindless patriotism a lot of people give to their countries - unquestioned defensiveness. I think it is pretty ignorant how a lot of people dismiss other users' criticism of Mac deficiencies by saying that certain features are not really needed, or can be done in some other roundabout way. If I need a certain feature, I generally need it. Period. It is not appropriate to dismiss my need with a "You don't really need to do that" argument. Eric Mitchell ============================================================================= Disclaimer: What?!? You took me seriously?!? HA HA HA HA HA HA !!!!!
awessels@walt.cc.utexas.edu (Allen Wessels) (07/12/90)
In article <893@mdavcr.UUCP> van-bc!mdavcr!ewm writes: >This begs the point. At least with a CLI you CAN easily invoke >programs to do things like deleting files in nested directories. I can do it just as easily with the Mac interface. A command key to invoke the DA, another to bring up the parameter dialog and a return key to set the process in motion. Not hard at all. >I find one of the greatest pains of the Mac OS is the difficulty of >executing small utility programs. One generally has the choice of I'd agree that it is difficult to run a seldom-used utility on one or two files, but people in general don't need to do it. I do occasionally and that lack is one of my complaints about the OS as well. > a) dragging everything you ever use to the desktop There are several launchers available to help with that problem. > b) finding a third party utility that allows easier access to files This is equivalent to finding a third party program to run under the CLI. > c) clicking through nested levels of folders As opposed to typing a monstrous pathname to the target file? With the 3rd party Standard File dialog enhancers, I get along just fine. >What a drag ;-). Through my UNIX CLI, I can set paths to various >directores, then invoke programs by name, without specifying their exact >location. This permits me to sort my directories logically and still >have simple access to programs. There are seventy bezillion ways to do this on the Mac as well. The Finder is just a fancy program. There's no law that says you have to use it. The problem with the Mac OS is that it is structured and can be hard to get behind that structure. For people who do lots of work with files rather than within files, this can be a tough problem to overcome. >Another problem is that CLI invoked programs can be made much simpler >than the typical MAC application, since there is no nead to support a >user interface. In UNIX, parameters can be passed to the program by >typing them on the same CLI line when invoking the program. Very handy >if you need to execute some utility program (like "find", "grep", >"more", etc) quickly. On the Mac, one has to invoke the program, then >wait for some user interface (ie: dialog box) to come up, then enter >the parameters in the correct place, etc. This means greater user >overhead, greater programmer overhead, and greater CPU overhead. The flip side of the coin is that with an interface, you don't have to remember parameter orders or fancy switches or the proper syntax to pipe the files etc. Would you rather spend your "user overhead" on waiting for a dialog to pop up (not too long a wait), or trying to remember the correct syntax for a command? I can think of operations on the Mac that wouldn't be too easy to accomplish in a CLI too. > >This leads to yet another deficiency - the lack of a CLI scripting >language. While the Mac now has a number of Macro utitlities >available, they are a poor substitute. (At least the ones I've seen - >If you can suggest a good one, TELL ME, PLEASE). One of the great >things about UNIX is the ability to take a bunch of small utility >programs and assemble them in a CLI script to perform some operation >that you need. I use this all the time (power user?). One of the things that can define a power user is the kind of task that user requires of the OS. I personally like that way I can pile dozens of inits into the OS and have all those functions enhancing the functionality of my machine. (power user?) The best CLI for the Mac is probably MPW. I suspect that its scripting facility can accomplish many of the things you require, though I'm no expert. >- unquestioned defensiveness. I think it is pretty ignorant how a lot >of people dismiss other users' criticism of Mac deficiencies by saying >that certain features are not really needed, or can be done in some I think you're ignoring the realities of the marketplace. How many of us need a Unix workstation at home? If you need it at work, there's AUX 2.0. First and foremost, an OS should be written for its intended market, not the theoretical whims of somebody who has no idea of what I need in a machine. >other roundabout way. If I need a certain feature, I generally need it. >Period. It is not appropriate to dismiss my need with a "You don't >really need to do that" argument. In the "who has the best box" argument, I usually say that the Mac does what I need it for better than any other box out there. I'd not presume to think that my Mac does what you need better than your box. If we're looking at the best box overall, I think a good measure is what exactly the people using these machines will be able to them. I think the Mac would do quite well in such a comparison.
gchow@ipsa.reuter.com (george chow) (07/12/90)
In article <2977@tellab5.tellabs.com> kenk@tellabs.com (Ken Konecki) writes: >Power users, shmower users. There's no such thing as a power user. >People who use computers are users, plain and simple. Period. End of >story. I don't know where the term came from, but it's the stupidest >phrase I have ever heard. Can anybody even define what a power user is (as >opposed to a powerless user?). I find the best definition for a power user to be someone who uses a device plugged into an AC socket. ;) >Ken Konecki >"Eat well, stay fit, and die anyway" >e-mail:kenk@tellabs.com -or- ...!uunet!tellab5!kenk >U.S. Mail: 1271 Portchester Circle, Carol Stream, IL 60188
ngg@bridge2.ESD.3Com.COM (Norman Goodger) (07/12/90)
In article <30285@eerie.acsu.Buffalo.EDU> jmpiazza@sybil.cs.Buffalo.EDU (Joseph M. Piazza) writes: > > I think what Mr. Strobl was referring to the fact that the >Finder was not originally designed to multitask -- not even cooperative >multitasking. While "kludge" may be an exageration, Multifinder is a >revision of the the same non-multitasking Finder. > > In this light I can't see how you can justify calling him ignorant. >Neither God nor Apple created the Mac in one day (though there are rumors >that Apple was present in the garden of Eden when Man and Women were >created :-) as was IBM in the guise of a serpent). :-) > Just as your memories of the pre-Multifinder era have faded. > joe piazza Since the original discussion had nothing to do with the "pre-MultiFinder era" whats the point? It was specifically refering to MultiFinder as I recall. I also don't think that MultiFinder is a revision of the non multitasking finder, since the Finder is runnning as a task or process under MultiFinder. -- Norm Goodger SysOp - MacInfo BBS @415-795-8862 3Com Corp. Co-SysOp FreeSoft RT - GEnie. Enterprise Systems Division (I disclaim anything and everything) UUCP: {3comvax,auspex,sun}!bridge2!ngg Internet: ngg@bridge2.ESD.3Com.COM
pbiron@weber.ucsd.edu (Paul Biron) (07/12/90)
In article <82023@tut.cis.ohio-state.edu> RD Francis <francis@cis.ohio-state.edu> writes: >It is perhaps important to note that the Finder is even now not >designed to multi-task, per se. Multi-tasking is handled by the >System; the Finder is simply a program that is used to manipulate >files and access other applications. > >Multi-Finder, as most Mac people know, is something of a misnomer. As ^^^^^^^^^^^^^^^^^^^^^^^^^^ see below. >far as I am aware, the Multi-Finder is simply a chunk of code that the >system uses to do multi-tasking. It is, of course, true that this >code was added to the Mac a few years after it came out. However, I >do not know if it was necessary to make any significant changes to the >Finder in order for it to work with Multi-Finder. > >-- >R David Francis francis@cis.ohio-state.edu It's even more of a misnomer than you think. When you switch between applications with Multi-Finder, the application you WERE using goes to sleep. I may be mistaken here, I don't get to use Multi-Finder very often because none of the Macs that I work on have enough memory. (If I am I'm sure someone will point it out :-) To be truely multi-tasking, an operating system must allow multiple processes (or applications) to be running AT THE SAME TIME (well, actually they each get a time slice). The closest thing to true multitasking I've seen on a Mac is the print spooler. Paul Biron pbiron@ucsd.edu (619) 534-5758 Central University Library, Mail Code C-075-R Social Sciences DataBase Project University of California, San Diego, La Jolla, Ca. 92093
pascal@altitude.CAM.ORG (Pascal Gosselin) (07/12/90)
I took find the lack of BATCH/SCRIPTING/CRON/PATHs on the Macintosh to be a MAJOR limitation. However, last week I got this flash at work while talking to our Apple Sales Rep (we are an Apple VAR). She was asking us "why" we could possibly NEED AU/X 2.0 since we do not sell Unix-Based software. I tried to explain to her that you could do all sorts of neat stuff with Unix, like Usenet/Mail (try explaining that to someone who's never witnessed the power of Unix mail facilities). The flash that I got was that there were some AWESOME possibilities for combining AU/X with the Mac OS to provide all sorts of automation that the Macro programs can't deliver. Imagine using UUCP mechanisms for automatic updating of multiple remote databases (with other AU/X based Macintoshes) that are actually MACINTOSH files, NOT Unix file systems. The demos I have seen of AU/X 2.0 seem to indicate that the overall interaction of the Mac OS and AU/X (including file systems) seem to be very high. I can already imagine LOTS of applications for using AU/X 2.0 to boost the brain-dead capacities of finder. What ever happed to the SCRIPTING language that was SUPPOSED to somehow be part of system 7.0 ? I'm not talking about IAC (Apple Events), I'm talking BATCH PROCESSING here. The Mac is dreadfully lacking batch modes, how can you automatically start 4 or 5 programs, back up a hard disk at 2:00am and run a conversion utility on 10 different files without doing a zillion mouse clicks and redoing every macro over because the desktop always has a different file/folder/disk placement??? In fact, last month Apple Canada spent 1/2 a day showing us how the OASIS architecture was to evolve as to eventually making the differences between a Mac running AU/X and Mac OS to be totally transparent to the user. AU/X 2.0 goes a long way to make UNIX available to everyday Mac users, but it's the Mac OS that needs to learn tricks from Unix now, not the other way around! -- +--------------------------------------------------------------------+ | Pascal Gosselin | Internet: pascal@altitude.CAM.ORG | | Gest-Mac Inc. Apple VAR | (514) 939-1127 CIS: 72757,1570 | +--------------------------------------------------------------------+
pbiron@weber.ucsd.edu (Paul Biron) (07/12/90)
In article <2619@network.ucsd.edu> pbiron@weber.ucsd.edu (Paul Biron) writes: >When you switch between applications with Multi-Finder, the >application you WERE using goes to sleep. I may be mistaken >here, I don't get to use Multi-Finder very often because none >of the Macs that I work on have enough memory. (If I am I'm >sure someone will point it out :-) > >To be truely multi-tasking, an operating system must allow >multiple processes (or applications) to be running AT THE >SAME TIME (well, actually they each get a time slice). > >The closest thing to true multitasking I've seen on a Mac >is the print spooler. > >Paul Biron pbiron@ucsd.edu (619) 534-5758 >Central University Library, Mail Code C-075-R >Social Sciences DataBase Project >University of California, San Diego, La Jolla, Ca. 92093 Sorry!!!!!! ;-( As *MANY* people have pointed out to me, Multi-Finder does *NOT* put applications to sleep when it switches between them. As I said above, the only Macs I've had access to in the last few years have only had 1 Meg of memory, so it hasn't been worth running Multi-Finder. The last time I used it was about 2 1/2 years ago, and I guess I just remembered incorrectly. Sorry, again! Paul Biron pbiron@ucsd.edu (619) 534-5758 Central University Library, Mail Code C-075-R Social Sciences DataBase Project University of California, San Diego, La Jolla, Ca. 92093
brendan@batserver.cs.uq.oz.au (Brendan Mahony) (07/12/90)
pbiron@weber.ucsd.edu (Paul Biron) writes: >When you switch between applications with Multi-Finder, the >application you WERE using goes to sleep. I may be mistaken >here, I don't get to use Multi-Finder very often because none >of the Macs that I work on have enough memory. (If I am I'm >sure someone will point it out :-) >To be truely multi-tasking, an operating system must allow >multiple processes (or applications) to be running AT THE >SAME TIME (well, actually they each get a time slice). >The closest thing to true multitasking I've seen on a Mac >is the print spooler. Multi-finder is multi-tasking, the background process will be given CPU time, as long as the foreground process does not require the CPU. The difference between this and pre-emptive multi-tasking is simply in the scheduling algorithm. Essentially the user has control does the scheduling, if the user doesn't require the attention of the foreground process the background process may take over. For me this is exactly what I want from a PERSONAL computer. I don't want the performance of the foreground process being degraded by some tyranical scheduler. On this Sun I sometimes have to wait many seconds before the computer reacts to a mouse-click. This is really annoying when trying to access a menu. -- Brendan Mahony | brendan@batserver.cs.uq.oz | Department of Computer Science | University of Queensland | Australia |
nick@lfcs.ed.ac.uk (Nick Rothwell) (07/12/90)
In article <2619@network.ucsd.edu>, pbiron@weber (Paul Biron) writes: >It's even more of a misnomer than you think. >When you switch between applications with Multi-Finder, the >application you WERE using goes to sleep. I may be mistaken >here You are. Background applications keep running. The only distinction (as far as I'm aware) between foreground and background is that the application gets told when it's moved from one to the other. Oh, and things like menu bars, keyboard focus, and so on. This all depends on the tasks relinquishing control to each other - this is the crux. >The closest thing to true multitasking I've seen on a Mac >is the print spooler. I see a war about to start... :-) >Paul Biron Nick. -- Nick Rothwell, Laboratory for Foundations of Computer Science, Edinburgh. nick@lfcs.ed.ac.uk <Atlantic Ocean>!mcsun!ukc!lfcs!nick ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ Ich weiss jetzt was kein Engel weiss
russotto@eng.umd.edu (Matthew T. Russotto) (07/12/90)
In article <2619@network.ucsd.edu> pbiron@weber.ucsd.edu (Paul Biron) writes: > >It's even more of a misnomer than you think. >When you switch between applications with Multi-Finder, the >application you WERE using goes to sleep. I may be mistaken >here, I don't get to use Multi-Finder very often because none >of the Macs that I work on have enough memory. (If I am I'm >sure someone will point it out :-) You ARE mistaken, as anyone who has downloaded a file, decoded a Stuffit file, and used Microsoft Word all at the same time knows. >To be truely multi-tasking, an operating system must allow >multiple processes (or applications) to be running AT THE >SAME TIME (well, actually they each get a time slice). This happens, though the foreground application has to be willing to give up a time slice (by calling GetNextEvent or WaitNextEvent) > >The closest thing to true multitasking I've seen on a Mac >is the print spooler. You haven't looked hard enough. -- Matthew T. Russotto russotto@eng.umd.edu russotto@wam.umd.edu ][, ][+, ///, ///+, //e, //c, IIGS, //c+ --- Any questions? Hey! Bush has NO LIPS!
barnett@grymoire.crd.ge.com (Bruce Barnett) (07/12/90)
In article <33804@ut-emx.UUCP> awessels@walt.cc.utexas.edu (Allen Wessels) writes: >> c) clicking through nested levels of folders > As opposed to typing a monstrous pathname to the target file? Wrong answer. I cut and paste long pathnames on my Unix box just fine. It's like selecting icons, except they are filenames. And when you consider filenames can have embedded spaces and foreign characters, I could cut and paste Kanji filenames, even if I could not type them on my keyboard. Another method that some Unix boxes support is "Drag and Drop", where you can drag the file/object from the "finder" (or another application) to the desired application, which then opens it. This should be object oriented e.g. Drag it to a trashcan to delete it Drag it to a printer to print it Drag it to a tape to archive it Drag it to an application, which will open it, include it, etc. depending on the type of object selected and the application running. The Standard GetFile dialog is just awkward, especially when you want to handle two different contexts/applications. Much better to augment the selection mechanism that already supports multiple contexts (i.e. Finder) than to use a mechanism that forces you to repeat actions over and over again. -- Bruce G. Barnett barnett@crd.ge.com uunet!crdgw1!barnett
daveo@Apple.COM (David M. O'Rourke) (07/13/90)
pbiron@weber.ucsd.edu (Paul Biron) writes: >It's even more of a misnomer than you think. >When you switch between applications with Multi-Finder, the >application you WERE using goes to sleep. This is almost true. If you're using an older piece of software that doesn't call waitnextevent then it'll go to sleep. However properly written software under Multifinder does recieve time in the background and the process will be sched. >To be truely multi-tasking, an operating system must allow >multiple processes (or applications) to be running AT THE >SAME TIME (well, actually they each get a time slice). MultiFinder does this, see above. >The closest thing to true multitasking I've seen on a Mac >is the print spooler. In all the OS books I've read they have said that multitasking is a mech. for scheduling the processor. MultiFinder is a true multitaksing system, it is not a pre-emptive multitasking system. But even the "true multitasking" phrase is a misnomer, to have "true multitasking" requires you have a processor for each task. :-) Hope this helps. BTW: Flames, comments, arguments regarding MultiFinder being a co-operative MultiTasking system rather than a preemptive system will be ignored. This group, and the rest of the net have hashed out that discussion numerous times and any further discussion is pointless. The above information was provided to correct an incorrect statment, not to start a new OS discussion regarding MF's multitasking choice. -- daveo@apple.com David M. O'Rourke _______________________________________________________________________________ I do not speak for Apple in *ANY* official capacity.
awessels@walt.cc.utexas.edu (Allen Wessels) (07/13/90)
In article <BARNETT.90Jul12094938@grymoire.crd.ge.com> barnett@crdgw1.ge.com writes: >Wrong answer. I cut and paste long pathnames on my Unix box just fine. >It's like selecting icons, except they are filenames. And when you Oops, silly me, I though we were comparing the CLI with the Mac interface, not producing the ideal interface. I did say that there were things missing from the Mac interface. I miss both some of the power of the CLI and batch processing to name two. >consider filenames can have embedded spaces and foreign characters, I >could cut and paste Kanji filenames, even if I could not type them on >my keyboard. Right. The Mac of course, can do this as well. > >Another method that some Unix boxes support is "Drag and Drop", where >you can drag the file/object from the "finder" (or another >application) to the desired application, which then >opens it. This should be object oriented e.g. The Mac is headed this way, but Apple suffers from the "not invented here" syndrome. If some other machine already has a feature, Apple is loathe to include it in the System. Thank heaven the Lisa had "Stationery", or we might not be seeing it coming back. > Drag it to a trashcan to delete it > > Drag it to a printer to print it > > Drag it to a tape to archive it > > Drag it to an application, which will open it, include it, etc. > depending on the type of object selected and the > application running. Uh, what size screen are you assuming here? That is a lot of icons you have floating around. I'll admit that I liked the "drag to printer to print" feature of the Xerox 6085 I got to play with for a while. I don't know if this is the particular object oriented metaphor is what Apple is headed for. In spite of the name IAC, I wonder if applications are going to continue to be such distinct entities. Rather than bringing a document into an application, I wonder if bringing a particular application's toolset to bear on the document might not be the direction things are heading for. >The Standard GetFile dialog is just awkward, especially when you want >to handle two different contexts/applications. Much better to augment >the selection mechanism that already supports multiple contexts (i.e. Finder) >than to use a mechanism that forces you to repeat actions over and >over again. Well, I'll agree that it will probably go away someday, but most people don't do the kind of operations you're describing. Apple's attitude seems to be that if people in general won't need to do it, they should be confused by the presence of the option. I don't particularly like this attitude, but if I have to deal with it to get a Mac, so be it.
n138ct@tamuts.tamu.edu (Brent Burton) (07/13/90)
In article <2619@network.ucsd.edu> pbiron@weber.ucsd.edu (Paul Biron) writes: >> . . . >>designed to multi-task, per se. Multi-tasking is handled by the >>System; the Finder is simply a program that is used to manipulate >>files and access other applications. >> >>Multi-Finder, as most Mac people know, is something of a misnomer. As > ^^^^^^^^^^^^^^^^^^^^^^^^^^ >To be truely multi-tasking, an operating system must allow >multiple processes (or applications) to be running AT THE >SAME TIME (well, actually they each get a time slice). > >Paul Biron pbiron@ucsd.edu (619) 534-5758 I run MultiFinder all the time on my 4meg Mac +. I always need to up/dn load files and If I need to do other things, the file transfer goes to the back. Multifinder gives each program "a time slice". Each program also tells MF how long MF has to do other tasks. WaitNextEvent (??) has an integer parameter that tells how much time MF shall get. Other programs may "go to sleep", but it is not like Switcher. Programs under Switcher _stopped_, while under Multifinder, they slow down(according to the integer in WaitNextEvent). Several small programs exist to show the "multitasking" ability of MultiFinder. One demo people like is MacEyes. I'll just do basic Finder-type activities and the eyes follow me around. Both programs are doing what they are supposed to do. Isn't this multitasking? I think it is for all practical purposes. Brent Burton n138ct@tamuts.tamu.edu
brh@hare.udev.cdc.com (brian r hanson x6009) (07/13/90)
> As for deleting a number of files in nested directories, no CLI > (command line interface) I have ever used can do this. The command language used on mainframes sold by Control Data is called SCL and supports wild card expressions on commands tailored to the type of data the command expects to see. With the standard command to delete a catalog ` (directory) you can delete all nested directories. With the standard command to delete one or more files you can delete files in nested catalogs which match the wild card expression. delete_file files=$working_catalog.$next.a* will delete all files in all subdirectories of $working_catalog which start with "a".
strobl@gmdzi.UUCP (Wolfgang Strobl) (07/14/90)
(kenk@tellabs.com (Ken Konecki) writes, after questioning the validity of the word "power user" (which I agree to): >As for deleting a number of files in nested directories, no CLI >(command line interface) I have ever used can do this. All the ones I >have seen must invoke another program to accomplish it (e.g. the Unix >shells would call the find command). And, with few exceptions, a CLI is >only as good as the programs it invokes. The shareware command line interpreter 4dos has a builtin command GLOBAL. By the way, 4dos works well under Windows 3. Now if they only would create a Windows-specific version ... Wolfgang Strobl #include <std.disclaimer.h>
barr@Apple.COM (Ron Barr) (07/14/90)
daveo@Apple.COM (David M. O'Rourke) writes: >pbiron@weber.ucsd.edu (Paul Biron) writes: >>It's even more of a misnomer than you think. >>When you switch between applications with Multi-Finder, the >>application you WERE using goes to sleep. > This is almost true. If you're using an older piece of software that >doesn't call waitnextevent then it'll go to sleep. However properly written >software under Multifinder does recieve time in the background and the process >will be sched. It's even better than this. I am writing this using a terminal emulation package written PRIOR to MultiFinder and background applications work fine. This application downloads in the background as well even though it was written for a single process OS. I think this speaks to Apple's commitment to orderly growth. An application can be switched out whenever it calls the old fashioned GetNextEvent as well. >-- >daveo@apple.com David M. O'Rourke >_______________________________________________________________________________ >I do not speak for Apple in *ANY* official capacity. Ron
drd@siia.mv.com (David Dick) (07/14/90)
In <1990Jul11.203141.820@ipsa.reuter.com> gchow@ipsa.reuter.com (george chow) writes: >In article <2977@tellab5.tellabs.com> kenk@tellabs.com (Ken Konecki) writes: >>Power users, shmower users. There's no such thing as a power user. >>People who use computers are users, plain and simple. Period. End of >>story. I don't know where the term came from, but it's the stupidest >>phrase I have ever heard. Can anybody even define what a power user is (as >>opposed to a powerless user?). A power user is someone who must have the latest personal computer and accessories (hardware and software) no matter what they cost :-) David Dick Software Innovations, Inc. [the Software Moving Company (sm)]