tonyrich@titanic.cs.wisc.edu (Anthony Rich) (01/06/90)
In article <8315@cbnewsm.ATT.COM> mls@cbnewsm.ATT.COM (mike.siemon) writes: >The example of reading an arbitrary file is just that, an example of a >much larger general problem. If I have a file I may want to use it in >a number of different ways, totally unconstrained by the file's origin >or by my intentions when I create the file. [...stuff deleted...] >But you cannot specify an arbitary file and an arbitrary application TOGETHER. >A new application may know all sorts of neat conversions to operate on >earlier kinds of output; the older applications are then practically >guaranteed to be unable to cope with the output of the new one. We seem to have another religious war heating up here. This real issue seems to be "Should operating systems do typechecking (between files and applications?)" This is analogous to the Pascal vs. C religious war about typechecking. Some people hate Pascal because it "forces" you to feed the right type of data to an operation, whereas C "liberates" you by allowing you to feed data of any type to an operation (whether it makes sense to do so or not). Others love Pascal because it prevents you from making the mistake of feeding bad data to an operation, thereby saving you long hours trying to track down insidious bugs. These people hate C because it's too easy to write programs that contain undiscovered mistakes. The same arguments hold about Mac vs Unix/MSDOS applications and files; just substitute the word "application" for "operation" and "file" for "data." Unix is like C; it lets you feed any file (a typeless stream of bytes) into any application, whether it makes sense to do so or not. (Liberating? Dangerous?) The Mac associates a type with each file, "forcing" you to only feed files of the right type to a program prepared to handle it. (Safer? Too restrictive?) The same arguments apply in both religious wars. Sure, it's nice to have the flexibility in a Unix-like system to process textfiles in virtually any program, but one penalty is that every program has to start with data that's in least-common-denominator form (raw text). One advantage of file types is that Mac applications can work with fancy file formats (TIFF, NFNT, whatever) without having to convert to/from a lowest-common-denominator raw text stream each time, and users are protected from accidentally doing unnerving things like displaying binary object code on the screen (I think everyone's done that at least once on Unix using "cat"!). A disadvantage of special file types is that they make it hard to write general-purpose utilities that can be pipelined together in flexible ways (i.e., forming bigger tools out of several little ones). That's why many Mac programs tend to be large, "try to do it all" programs rather than small, single-purpose utilities. The overall problem is being (partly) solved in the programming-languages world by object-oriented, hierarchical type systems which "factor out" the common characteristics of different data objects. That way, an operation can be applied to any data item that is of a certain type OR ANY SUBTYPE OF IT. If the Finder had that capability, it would be possible tell it that a TEXT file is a subtype of the file formats used by Microsoft Word, MacWrite, WordPerfect, etc. Then when you double-clicked on a TEXT file, the Finder would know that any of those word processors could be launched safely. (Perhaps a list of word processing applications would pop up, allowing you to pick your favorite.) Distributing a simple text program with the OS (like TeachText is) would then guarantee that SOMETHING useful would get launched, which I think is where this whole discussion about "text file madness" got started. I hope this armchair analysis heads off WFW III (World Flame War III ;^). -- ------------------------------------------------------------- Email: tonyrich@titanic.cs.wisc.edu Phone: 608-271-8450 US mail: Tony Rich, 4321 Sentinel Pass, Madison, WI 53711 -------------------------------------------------------------
folta@tove.umd.edu (Wayne Folta) (01/07/90)
In article <9505@spool.cs.wisc.edu> tonyrich@titanic.cs.wisc.edu (Anthony Rich) writes:
"Sure, it's nice to have the flexibility in a Unix-like system to process
"textfiles in virtually any program, but one penalty is that every program
"has to start with data that's in least-common-denominator form (raw text).
I was thinking about this the other day. One of the things that propelled
UNIX forward was its elegant concept of filters and pipes. UNIX started with
(and still almost exclusively uses) a command-line interface, so the idea
of pipes--though brilliant--was easy to implement: a program's output can be
sent to another program instead of the user.
This (and the fact that the original UNIX output to a teletype) pushed UNIX
to give very terse output... While users might like more readable output,
that would "gum up" filters with a lot of extraneous information.
So... It seems that pipes might constrain the UNIX UI to stick with terse ASCII,
otherwise, you get a dichotomy: ASCII between filters, but not to the user.
There are ways around this, I guess... But UNIX does not seem to have any
non-ASCII lowest common denominators. (For example, the Mac has MacWrite,
MacPaint, MacDraw, and maybe TIFF and AIFF as its lcd.) Or, I guess, a whole
new set of filters need to be made?
PLEASE! I am not trying to expand a DOS/Mac war into a UNIX/Mac war. I
am just cogitating on whether some of UNIX's strengths might hold it back now.
(I have used UNIX for 10 years now, and I do like it.)
--
Wayne Folta (folta@cs.umd.edu 128.8.128.8)lai@Apple.COM (Ed Lai) (01/07/90)
In article <9505@spool.cs.wisc.edu> tonyrich@titanic.cs.wisc.edu (Anthony Rich) writes: > I have deleted all that, but I think it is a good analysis. >A disadvantage of special file types is that they make it hard to write >general-purpose utilities that can be pipelined together in flexible ways >(i.e., forming bigger tools out of several little ones). That's why many >Mac programs tend to be large, "try to do it all" programs rather than >small, single-purpose utilities. > Actually I do not think that because data are typed means that it more difficult to write utilities that can be pipelined together, it just mean that you cannot plug together tools that are not meant to be plugged together, a point that you already made. Then what if we need to plug 2" pipes (borrowing analogy from plumbing) to 1" pipes? What you need is adaptors. Finally there should be wildcard type that is universal (e.g. a hex dump tool can dump any type of data into TEXT). If anybody have use the Clipboard magician DA, they would see that this is the principle behind it. /* Disclaimer: All statments and opinions expressed are my own */ /* Edmund K. Lai */ /* Apple Computer, MS75-6J */ /* 20525 Mariani Ave, */ /* Cupertino, CA 95014 */ /* (408)974-6272 */ zW@h9cOi
mls@cbnewsm.ATT.COM (mike.siemon) (01/07/90)
In article <9505@spool.cs.wisc.edu>, tonyrich@titanic.cs.wisc.edu (Anthony Rich) writes: > In article <8315@cbnewsm.ATT.COM> mls@cbnewsm.ATT.COM (mike.siemon) writes: > >The example of reading an arbitrary file is just that, an example of a > >much larger general problem. If I have a file I may want to use it in > >a number of different ways, totally unconstrained by the file's origin > >or by my intentions when I create the file. > We seem to have another religious war heating up here. This real issue > seems to be "Should operating systems do typechecking (between files and > applications?)" Well, actually, no. I cancelled my original article, because it was a bit flamish and not terribly helpful about "what to do." It seems to have got out to a few sites anyway, so maybe I should add some justification. The "problem" is that we are *always* generating data for some purpose or other (on paper or in variously formatted files) and then we discover that we'd like to *do* something with this data. If the purpose *precedes* the generation of the data, then one can imagine a Mac-like interface working very well -- simply create the data in the ultimately desired format, or generate it and then immediately go into the "destination" utility and set things up for further use there. But the fact is the - we *don't* always know at the outset how we are going to use data - we often think of new things to do with our data *after* it has been created. Again, I need to emphasize that there is *no problem* with the Mac interface in dealing with such things on a custom basis. One simply follows through with the particular data until it has reached its proper destination. But the larger issue is the *reuse* of data, and the use of data for purposes beyond those that generated it in the first place. Human intelligence is a very open-ended thing, and one of its principle characteristics is a sort of self-reference. Once we *have* something, we immediately proceed to use it in a way different from the way in which we first conceived it. The power of abstraction and reuse is so vital to human thought that it really *should* be built into any computer system that attempts to respond to NEW thinking. The Mac is fine, as long as you *only* do what someone else wants you to do with it. -- Michael L. Siemon I say "You are gods, sons of the cucard!dasys1!mls Most High, all of you; nevertheless att!sfbat!mls you shall die like men, and fall standard disclaimer like any prince." Psalm 82:6-7
allbery@NCoast.ORG (Brandon S. Allbery) (01/08/90)
As quoted from <9505@spool.cs.wisc.edu> by tonyrich@titanic.cs.wisc.edu (Anthony Rich): +--------------- | In article <8315@cbnewsm.ATT.COM> mls@cbnewsm.ATT.COM (mike.siemon) writes: | >The example of reading an arbitrary file is just that, an example of a | >much larger general problem. If I have a file I may want to use it in | >a number of different ways, totally unconstrained by the file's origin | >or by my intentions when I create the file. | | Dangerous?) The Mac associates a type with each file, "forcing" you to only | feed files of the right type to a program prepared to handle it. (Safer? +--------------- No -- you can override it very easily: select the application and the file you want opened, then select "Open" from the File menu. Of course, what MacWrite will do when you tell it to open Suitcase II is open to question... but then again, so is "cat /unix". +--------------- | Mac programs tend to be large, "try to do it all" programs rather than | small, single-purpose utilities. +--------------- This is less a problem of file types than one of a lack of IPC... which Apple is fixing in System 7.0. Small, single-purpose utilities *demand* some form of IPC, whether it be Unix pipes, VMS mailboxes, or etc. A simple Mac solution would be to allow any application to launch another application with the option that a new clipboard should be created for use in communication between those two applications. File types do come into it -- but you have to be able to get the data transferred between two applications before you can worry about what they'll do with it. ++Brandon -- Brandon S. Allbery allbery@NCoast.ORG, BALLBERY (MCI Mail), ALLBERY (Delphi) uunet!cwjcc.cwru.edu!ncoast!allbery ncoast!allbery@cwjcc.cwru.edu *(comp.sources.misc mail to comp-sources-misc[-request]@backbone.site, please)* *Third party vote-collection service: send mail to allbery@uunet.uu.net (ONLY)*
mitchell@cbmvax.commodore.com (Fred Mitchell - PA) (01/10/90)
Ok. Now how about a Amiga/Mac war, or a PC/Unix war or a (worse)
Amiga/Mac/Unix/PC War!!!! :-) Ushering in WFW IV :-) :-) :-)
It seems that each of these machines have a whole different philosophy
unto themselves. PC's philosophy is: "Slap it toghether- if it works,
they'll buy it!" Well, IBM has pulled that trick off for a while.
Unix's philosophy is, "pile up all the programs to make one, huge, massive
OS." This works. I kinda like Unix, while at the same time, being intimidated
(me intimidated? :-) by its sheer size.
Mac, on the other hand, says, "give
them a pretty interface that's also easy to use. Leave as few choices as
possible, though, to the user." Well- I have seen some of the applications
for the Mac and I am impressed with them. But the Mac has a 'minor' burden
of this OS that is both glorious and cumbersome- it offers alot of great
tools, but the arbitration to allow multiple tasks to run was thrown in
as an afterthoght, unfourtunatly. Whatever happened to Lisa? I remember
being tempted by this lady, but being disapointed by here monolithic outlook
on life- black & white. Same for the first Macs. Well, there's MacII & ci
and that's a step in the right direction, but, alas, the burden remains.
And then there is the Amiga. Almost like an orphan- due to its initial lack
of marketing. A marvel of a machine snatched up by a company that almost didn't
know what to do with it. But, ah yes, the light has finnaly come. The first
few years was a hard struggle, but the machine survived. And now, over a
million strong, it will take its rightfully-earned place in the world. The
thing the Amiga offers the most is the choice. The choice to do it your way,
anyway you want.
And now who will claim the crown? Who will carry the torch? Who will
eventually arise to the very top? Time will tell. There will be many
wars, religious followings on all camps. But only time will tell.
-Mitchell
DISCLAIMER: The above are totally my own thoughts and insights. They shall
not be held related in anyway to They who employs my mind, or
They who directs my actions. The above is not in any way intended
to trigger an escalation to nuclear proportions. I call'em as I
see'em. Enjoy or take with a grain of salt.Jerry.Andrews@f426.n109.z1.fidonet.org (Jerry Andrews) (01/11/90)
FM> as an afterthoght, unfourtunatly. Whatever happened to Lisa? I remember We have several Lisa's, but really -- they're slow, less powerful cousins to the Macs. Most have been backfitted with Mac OS's. At the time it was released, the Lisa was glorious, but the Macs do the same things so much faster and in so many more ways, that, well, it's like the venerable CP/M machine here next to me: useful, still, but not much used. Too slow, too vulnerable. -- Jerry Andrews at The Black Cat's Shack (Fidonet 1:109/401) Internet: Jerry.Andrews@f426.n109.z1.fidonet.org UUCP: ...!uunet!blkcat!426!Jerry.Andrews
mls@cbnewsm.ATT.COM (mike.siemon) (01/11/90)
In article <1990Jan7.172731.12580@NCoast.ORG>, allbery@NCoast.ORG (Brandon S. Allbery) writes: > +--------------- > | In article <8315@cbnewsm.ATT.COM> mls@cbnewsm.ATT.COM (mike.siemon) writes: > | >The example of reading an arbitrary file is just that, an example of a > | >much larger general problem. If I have a file I may want to use it in > | >a number of different ways, totally unconstrained by the file's origin > | >or by my intentions when I create the file. > +--------------- > No -- you can override it very easily: select the application and the file > you want opened, then select "Open" from the File menu. This is a bit obscure. If I try to select, e.g., the file generated by my scanner software *and* a word processor, I find that the Finder doesn't *let* me extend selections across different folders. (surely you *don't* mean for me to keep everything in the *same* folder? :-)) I can of course drag one of these to the *other's* folder, or both onto the desktop (and then must remember to drag them back where I really want them :-)) Now if I click and shift click (or whatever) to select them both, a double click may launch the application *with* the file I want (at least, Word did this for me; I really don't know if this is general or not. One *never* knows whether something on the Mac is general or not.) Thus, I do not need the File menu's Open line -- at least in this case. I was unaware of the possibility until you mentioned it; are you suggesting this is known to ordinary Mac users? It is not mentioned in Apple documentation that I have read. Or are you suggesting that ordinary Mac users will divine this incantation from ordinary use, or that *all* combinations of selections and menu choices give some reasonable result? Or that I am supposed to spend hours "playing" with this box to "see what happens" in all the potential situations that could be generated by mouse operations? (And what then; must I write my own documentation to record these experimental findings?) My scanner software tries to by "nice" to me by allowing its output to be in Word or MacWrite format. So does my communications software, but neither of them knows about Nisus, for example. (And why *should* they?) But suppose I want to add the numbers that happen to be in the third column of this text file I just scanned in. A spreadsheet program might or might not be able to cope with this file. If WordPerfect on the Mac has the same facilities as on PCs, *it* might be able to do the add (after some silliness or other; for all I know Word may have buried arithmetic capabilites, too -- possibly hanging off the KitchenSink menu.) Do you begin to see what I'm talking about? Either everything has to *know* about everything else -- impossible unless you forbid innovation, as in the Lisa -- or else one has to have general combinators or constructors for the complex operations that actually describe what people *want* to do. It is no answer to say that I can do anything by step-by-step elemetary operations. Theoretically, the only operations editors *need* are deletion and insertion. I would *not* recommend an editor that used only the elementary operations. UNIX has major deficiencies, particularly in a visual interface. I am not aruging that the Mac should be "like" UNIX in any obvious way (and UNIX too has the problem of one not knowing what will generalize -- one of the BUGS sections in an early UNIX command notes that its syntax is "rebarbative.") But Ritchie and Thompson's original ACM article about UNIX makes one very good point that is almost always lost in these later discussions. The idea of *all* files being byte sequences, connected via stdin/stdout pipes in a *general* combinator, has all the power that algebra does in mathematics. The Mac draws beautiful Roman numerals; one is almost seduced into thinking that the art of reckoning with these numerals is all there is to mathematics. -- Michael L. Siemon In so far as people think they can see the cucard!dasys1!mls "limits of human understanding", they think att!sfbat!mls of course that they can see beyond these. standard disclaimer -- Ludwig Wittgenstein
dave@PRC.Unisys.COM (David Lee Matuszek) (01/13/90)
In article <8454@cbnewsm.ATT.COM> mls@cbnewsm.ATT.COM (mike.siemon) writes: > >This is a bit obscure. If I try to select, e.g., the file generated by my >scanner software *and* a word processor, I find that the Finder doesn't *let* >me extend selections across different folders. (surely you *don't* mean for >me to keep everything in the *same* folder? :-)) That's the way it works. It made a lot more sense back when I bought my 128K Mac; back then MFS had folders, but they were just an organizational convenience, not really used by the operating system. When HFS (and reasonably-priced hard disks) came along, folders were used to implement the directory hierarchy. It seems to me that this feature still exists primarily for compatibility reasons. [BTW, I never found it particularly useful anyway.] >I can of course drag one of these to the *other's* folder, or both onto the >desktop (and then must remember to drag them back where I really want them >:-)) Now if I click and shift click (or whatever) to select them both, a >double click may launch the application *with* the file I want (at least, >Word did this for me; I really don't know if this is general or not. One >*never* knows whether something on the Mac is general or not.) You never know what's general on *any* computer, but I think the Mac is a great deal more consistent than most. For example, I use Unix at work; for some commands that I don't use every day, there are parameters that may or may not require a '-' prefix (e.g. the history command). > Thus, I do >not need the File menu's Open line -- at least in this case. I was unaware >of the possibility until you mentioned it; are you suggesting this is known >to ordinary Mac users? Well, I don't know about you new kids on the block, but us old-timers all know about it.... > It is not mentioned in Apple documentation that I >have read. It's fully described in my docmentation. Of course, it's been several years since I got updated docs, even longer since I looked at the docs I do have. > (And what then; must >I write my own documentation to record these experimental findings?) The "Macintosh Bible" is a great book; I highly recommend it. It makes up for a lot of failures in the official documentation (which was clearly written for "the rest of them"). [I've never met a computer that comes with really good documentation; unfortunately, this includes the Mac.] > for all I know Word may have buried arithmetic capabilites, too -- >possibly hanging off the KitchenSink menu.) I don't know about Word 3.x, but yes, Word 4.0 does have arithmetic capabilites. I forget which menu, as usual. But please don't judge the Mac by MS Word. MS Word is widely regarded as one of the most "un-Mac-like" programs around, despite the fact that it's the most widely used word processor. > The idea >of *all* files being byte sequences, connected via stdin/stdout pipes in a >*general* combinator, has all the power that algebra does in mathematics. Yes, this is a great idea. But the Macintosh has some pretty good ideas, too. The idea of "resources" is pretty darned useful. Less important, but more visible, I like the fact that files have types, so that I don't have to keep track of this myself (and no, filename extensions aren't in the same class). > >The Mac draws beautiful Roman numerals; one is almost seduced into thinking >that the art of reckoning with these numerals is all there is to mathematics. > Does anyone out there have a Roman numeral Desk Calculator DA? Sounds like a fun thing to have. -- Dave Matuszek (dave@prc.unisys.com) -- Unisys Corp. / Paoli Research Center / PO Box 517 / Paoli PA 19301 -- Any resemblance between my opinions and those of my employer is improbable. << Those who fail to learn from Unix are doomed to repeat it. >>
allbery@NCoast.ORG (Brandon S. Allbery) (01/13/90)
As quoted from <8454@cbnewsm.ATT.COM> by mls@cbnewsm.ATT.COM (mike.siemon): +--------------- | In article <1990Jan7.172731.12580@NCoast.ORG>, allbery@NCoast.ORG | (Brandon S. Allbery) writes: | > +--------------- | > | In article <8315@cbnewsm.ATT.COM> mls@cbnewsm.ATT.COM (mike.siemon) writes: | > | >much larger general problem. If I have a file I may want to use it in | > | >a number of different ways, totally unconstrained by the file's origin | > +--------------- | > | > No -- you can override it very easily: select the application and the file | > you want opened, then select "Open" from the File menu. | | This is a bit obscure. If I try to select, e.g., the file generated by my | scanner software *and* a word processor, I find that the Finder doesn't *let* | me extend selections across different folders. (surely you *don't* mean for | me to keep everything in the *same* folder? :-)) +--------------- Admitted, it's a pain---but it *does* exist. No doubt a clever INIT could exploit this. +--------------- | not need the File menu's Open line -- at least in this case. I was unaware | of the possibility until you mentioned it; are you suggesting this is known | to ordinary Mac users? It is not mentioned in Apple documentation that I | have read. Or are you suggesting that ordinary Mac users will divine this +--------------- The Macintosh SE manual, page 169, third paragraph of the section labeled "Open". Of course, I may be the only person in the world who actually *reads* manuals upon receiving them.... +--------------- | Do you begin to see what I'm talking about? Either everything has to *know* | about everything else -- impossible unless you forbid innovation, as in the +--------------- I believe I mentioned this (comment about MacWrite's response to opening the Suitcase II INIT). But---as I said then---it's no different than you get from e.g. UNIX or MS-DOS, etc. ++Brandon -- Brandon S. Allbery allbery@NCoast.ORG, BALLBERY (MCI Mail), ALLBERY (Delphi) uunet!cwjcc.cwru.edu!ncoast!allbery ncoast!allbery@cwjcc.cwru.edu *(comp.sources.misc mail to comp-sources-misc[-request]@backbone.site, please)* *Third party vote-collection service: send mail to allbery@uunet.uu.net (ONLY)*
mls@cbnewsm.ATT.COM (mike.siemon) (01/14/90)
In article <12501@burdvax.PRC.Unisys.COM>, dave@PRC.Unisys.COM (David Lee Matuszek) writes: > > for all I know Word may have buried arithmetic capabilites, too -- > > possibly hanging off the KitchenSink menu.) > > I don't know about Word 3.x, but yes, Word 4.0 does have arithmetic > capabilites. I forget which menu, as usual. But please don't judge > the Mac by MS Word. MS Word is widely regarded as one of the most > "un-Mac-like" programs around, despite the fact that it's the most > widely used word processor. My point was not Microsoft-bashing nor judging the Mac by its most-used application. The point is that it is absurd to expect Word, or any other program, to have the capability to do *anything* that I might happen to want to do with some generic file (scanned in, downloaded, or whatever.) The problem is how to COMBINE data (files) of many different types and sources with operations (applications) of equally diverse origins and type. And as a combinatorial problem, it *must* be handled abstractly or else it simply cannot be handled beyond the first few steps of complification. What we tend to get are appplications that *sort of* do everything they *think* we need -- word processors that aspire to page layout, that have built-in drawing programs, built-in style-checkers, built-in spreadsheets and so on _ad infinitum_. Such an approach is *not* general -- it is simply an expensive ginsu knife. The use of DAs, and even more of CDEVs, relieves the problem considerably -- for example, I can use the same spelling checker in any text-oriented program (as long as it implements the Edit menu adequately.) More of that kind of *orthogonal* functionality is what is needed. For example, while in my word processor, I drag out a selection of some columns of figures, operate on these by invoking a Mathematica sort of package whose results I feed into a digital darkroom in order to get a picture that I place in the original text I started working on. Now I start commenting on the features of this image, and decide that I need further image-enhancement, so I tweak the transformations either in the math package or the darkroom. Clipboards and DAs and such *suggest* this kind of functionality, but they also fragment it into unique individual operations, and there is no "metalanguage" -- no algebra -- in which to decribe *always* doing that text -> math -> image-processing -> page layout operation (or better still, conditionally doing it!) at that stage in a document. What I have in mind is any application being able to open any other application in some local context (up to the whole document) of the current file. The CMU Andrew environment seems to me to exhibit this sort of generality in a way the Mac does not. (Speaking from a *very* slight aquaintence with that, and no personal use of it; Andrew users might enlighten me as to whether there is more promise than reality in this view of things!) At any rate, Andrew comes closer to a 2-D generalization of the UNIX pipe- line model than anything else that has come to my attention. -- Michael L. Siemon There is no algorithm for human interaction. ...!cucard!dasys1!mls There is no decision procedure for tuning ...!att!sfbat!mls into other people's emotions. standard disclaimer -- Mara Chibnik
mls@cbnewsm.ATT.COM (mike.siemon) (01/14/90)
In article <1990Jan13.001703.24286@NCoast.ORG>, allbery@NCoast.ORG (Brandon S. Allbery) writes: > The Macintosh SE manual, page 169, third paragraph of the section labeled > "Open". Of course, I may be the only person in the world who actually *reads* > manuals upon receiving them.... Well, no. But guided by your remark, I find the equivalent paragraph on p.181 of my Mac II manual. This encourages me to reread the manual, which I had put aside, as my reading of it on first receipt left me with an impression that it was wordy and uninformative. I must note, sadly, that it has *no* indexing of any kind, not even the (marginally helpful) permuted index listing in UNIX manuals. The paragraph in question even continues on to an answer for the question that immediately came to my mind reading the paragraph Brandon cites: If you select more than one icon and choose Open, the Finder tries to open the first icon's application to work on all the other selected icons... which I regard as well thought out -- except of course that it still cannot cope sensibly with large file systems organized in many folders, and there is still the problem of selecting arbitrary subsets within a large set of files (the problem UNIX fumbles around by regular pattern matching in the shell; I do not claim that the UNIX method is "the answer," but at least it provides *some* help (coloring icons, or spatially distributing them goes partway to the same sort of kludged answer on the Mac, as someone has pointed out.)) It is not clear to me whether I ever noticed the paragraph; certainly, by the time I ever had a file *not* created by the application I wanted to use (and hence almost certainly in a different folder) any trace of this option had long since vanished from my head. I do *not* have a photographic memory. (And my acquisition of useful applications has been somewhat slow, due to budgetary constraints :-)) Someone else in this thread mentioned the Macintosh Bible as a helpful source. I've browsed through that a couple of times, and always decided to *not* buy it -- a more randomly organized and useless collection of context-laden folk recipes would be hard to find outside a medieval grimoire or a 1950s American hobbyist's compendium of _Popular Mechanics_. Again, my point in all of this is *not* that the Mac is "bad" -- it has many elements of a good visual interface, and it has these by design. The problem remains one of generalizing the elementary operations that the Mac does well so that they can encompass complex structures *without* requiring me to do every bloody operation as a unique conscious effort.
Jerry.Andrews@f426.n109.z1.fidonet.org (Jerry Andrews) (01/15/90)
mA> Someone else in this thread mentioned the Macintosh Bible as a helpful mA> source. I wouldn't've bought it, either, but someone loaned it to me, and it sits on the shelf next to my Mac. Interesting observation (it was to me, anyway!): the more used to the Mac I get, the more I refer to the Bible for tips on whatever I'm working on at the moment. Yeah, it's random, and quirky, but it has something to say on nearly EVERYTHING. -- Jerry Andrews at The Black Cat's Shack (Fidonet 1:109/401) Internet: Jerry.Andrews@f426.n109.z1.fidonet.org UUCP: ...!uunet!blkcat!426!Jerry.Andrews
vita@daredevil.crd.ge.com (Mark F Vita) (01/16/90)
In article <8454@cbnewsm.ATT.COM> mls@cbnewsm.ATT.COM (mike.siemon) writes: >This is a bit obscure. If I try to select, e.g., the file generated by my >scanner software *and* a word processor, I find that the Finder doesn't *let* >me extend selections across different folders. (surely you *don't* mean for >me to keep everything in the *same* folder? :-)) > >I can of course drag one of these to the *other's* folder, or both onto the >desktop (and then must remember to drag them back where I really want them >:-)) Not at all. Go ahead and put the files you want to operate with onto the desktop. When you're done, just select 'em and choose "Put Away" from the File menu. The files will automagically go back from whence they came. A very handy and much-underutilized feature of the Finder (especially handy when used in conjuction with Find File's "Move To Desktop" command). Mark Vita vita@crd.ge.com General Electric CRD ..!uunet!crd.ge.com!vita Schenectady, NY