mxmora@unix.SRI.COM (Matt Mora) (01/23/91)
I realize that its probably to late for the programmers to change anything now but I have a few problems with system 7.0 1) WHY IN THE WORLD WOULD APPLE WITH ALL THEIR AWESOME PROGRAMMERS AND UNLIMITED R&D FUNDS CHOOSE TEACH TEXT AS THERE DEFAULT TEXT EDITOR!!!! THAT IS TRUELY ASSININE! Come on now. The finder should have an editor built in. If they can't write one then they can licence the code from someone. Edit 6.0 is only 68K in size. DataPak is selling some code to do the same thing. If the really want an awesome editor they can attach MPW's editor to it.(or even McSink DA) Even if they don't add an editor to the finder they should at least make the default program that it launches configurable. "I'm sorry, that file is to big for teach text to display" will probably be the message a user will get if they try to open a big read me file. Maybe I'm way off base here and Apple really feels that most users will not need a text editor, but there is nothing worse than having to read a large text file on a mac that only has a word processor. First you have to find the application because if the user just double clicks on the file of course they will get "application busy or not found dialog". Thats user friendly? How about giving a user a list of applications that can open the file like handoff does? Once you found the WP program (after digging through a few folders) you have to remember wher the file was and hunt for with the lovely SFGet file. Now that you found the file and open it, You have to wait and wait for the wonderful wp program to read in the text and format the page because we all know that everything on the mac has to look good. :-) Well it should look good but the silly user who wrote the document of course used hard <cr>'s and the margins in this now "untitled" document are smaller than the original and every thing is all over the place. Well of course there are a lot worse things in this world, this is a worse case sinaro (sp?) and stuff like this never happens, at least not on a Mac.:-) 2) Apple has open up the system file. This is great no more font/da mover. BUT WHAT ABOUT FKEYS? Come on Apple just a few changes to some source and you can also drag Fkey files into the system folder. Thats not asking too much. I don't remember if you can drag sound files but if not you should include them too. Sorry for the lengthy post but I had to get it off my chest. These are not the only things I thought of but its just the ones I can remember offhand. Matt -- ___________________________________________________________ Matthew Mora | my Mac Matt_Mora@QM.SRI.COM SRI International | my SUN mxmora@unix.sri.com ___________________________________________________________
francis@uchicago.edu (Francis Stracke) (01/23/91)
In article <20283@unix.SRI.COM> mxmora@unix.SRI.COM (Matt Mora) writes: I realize that its probably to late for the programmers to change anything now but I have a few problems with system 7.0 [...] Come on now. The finder should have an editor built in. If they can't write Text editors are about the most personality-subject apps around. If Apple gave us one, lots of us would complain about it. :-) [...] Once you found the WP program (after digging through a few folders) you have to remember wher the file was and hunt for with the lovely SFGet file. Now Your word processor really should be easy to find--if your directory structure makes it hard to find what you need, that's not Apple's fault. (IMHO and no offense meant. :-) SFGetFile is, I agree, not as nice as it could be--it would be nice if there were more user control (e.g., being able to mark a file from the Finder). Boomerang makes it nicer, but there are a few other things that would be nice. -- /=============================================================================\ | Francis Stracke | My opinions are my own. I don't steal them.| | Department of Mathematics |=============================================| | University of Chicago | Until you stalk and overrun, | | francis@zaphod.uchicago.edu | you can't devour anyone. -- Hobbes | \=============================================================================/
bskendig@dry.Princeton.EDU (Brian Kendig) (01/23/91)
[Apple dudes, please read down to the end of this; I have a few questions about System 7 that have nothing to do with TeachText. Honest. ;) ] In article <20283@unix.SRI.COM> mxmora@sri-unix.sri.com (Matt Mora) writes: >1) WHY IN THE WORLD WOULD APPLE WITH ALL THEIR AWESOME PROGRAMMERS > AND UNLIMITED R&D FUNDS CHOOSE TEACH TEXT AS THERE DEFAULT TEXT EDITOR!!!! > THAT IS TRUELY ASSININE! > >Come on now. The finder should have an editor built in. I disagree with that. I don't need a small general-purpose text editor; I'd rather not have to surrender memory and disk space to one if I can help it. Besides: (1) the Finder deals with files, and viewing text has little to do with files on a high level; and (2) Apple is working towards breaking software apart into little modules each of which does a specific task. Tacking TeachText or any other editor onto the Finder would be a step backwards in this regard. >If they can't write one then they can licence the code from someone. And increase their costs even more? What, you don't think the Macs cost too much already? ;) TeachText is nothing more than a vehicle for TextEdit, the text-display package built into the Macintosh. As such, it's restricted to the same things TextEdit is restricted to (it can't handle more than 32k of data, for example), but it's small, simple, and there's not a whole lot of room for bugs. >Even if they don't add an editor to the finder they should at least make the >default program that it launches configurable. "I'm sorry, that file is to big >for teach text to display" will probably be the message a user will get if >they try to open a big read me file. README files are, practically by definition, supposed to be concise and important notes that can't be missed even if the user doesn't feel like reading the docs; if they're long, why not make them into a manual instead? But even so, TeachText is made to display and edit short files. If they gave you something that's capable of handling longer documents (by putting time and money into rewriting TeachText or even redoing TextEdit itself -- not bloody likely), you might not run out and buy MacWrite or QUED or pay shareware for McSink. Apple's not in the application business. >Maybe I'm way off base here and Apple really feels that most users will not >need a text editor, but there is nothing worse than having to read a large >text file on a mac that only has a word processor. First you have to find the >application because if the user just double clicks on the file of course they >will get "application busy or not found dialog". Thats user friendly? Isn't that being fixed in System 7.0? Serious question here -- anyone? If it's not, and even if the dialogs complain something like "The aplication that created this document can not be found" and exit instead of offering to open it with another application that can read TEXT files -- THEN, I'd bash a few fruitcakes at Apple. >Once you found the WP program (after digging through a few folders) you have >to remember wher the file was and hunt for with the lovely SFGet file. Now >that you found the file and open it, You have to wait and wait for the >wonderful wp program to read in the text and format the page because we all >know that everything on the mac has to look good. :-) Well it should look good >but the silly user who wrote the document of course used hard <cr>'s and the >margins in this now "untitled" document are smaller than the original and >every thing is all over the place. I know what you mean! If it bothers you that TeachText documents take a long time to load into other WP's and look ugly when they get there, then why not keep a copy of TeachText on your hard drive? Either that, or put up with it for now; the stuff is still readable, and after all who wants to frame README files and hang them on walls? >2) Apple has open up the system file. This is great no more font/da mover. > BUT WHAT ABOUT FKEYS? Come on Apple just a few changes to some source > and you can also drag Fkey files into the system folder. Thats not asking > too much. I don't remember if you can drag sound files but if not you > should include them too. Hmm, good question, there. Apple? Anyone? I've played with System 7.0b1, but I eventually got rid of it. I seriously disliked a few things about it: - It was painfully slow on my Macintosh SE. I assume this is because there's still debugging code left in there because it's only a beta release; I certainly hope things aren't this draggy when it goes production! - I know the bit about icon positioning between System 6 and System 7 (how the icons are moved when you switch Systems) is being fixed -- but I don't like how, when I hit the zoom box, the window snaps to _precisely_ the right and bottom edges of the icons. Cuts it a bit close for my tastes; I find it easier to see if I leave some white space around my outermost icons. Could a `snugness' control be added? That, and a control for just how `staggered' the icons are when you set icon positioning to `staggered' -- I like each icons name to be _just_ above or below that of its neighbor, so I get the effect of having them in rows, but the names don't overlap. - Boy, that thing takes up a heckuvalotta my 2.5 megs of memory! Again, I hope this is because debugging code is hogging the space, and that the System will actually let me run more than one program at a time when it's finally released... - And could we please have a way to flip between active applications via the keyboard? Pretty please? It's annoying enough right now having to reach for the mouse to click on the Multifinder icon under System 6 to switch between my telnet session and my text editor, but now I have to actually pull down a _menu_? Bleah. Aside from that, everything looks peachy! (As long as you fix all the bugs. ;) Any more word yet, officially or through the grapevine, on when System 7 will be released? << Brian >> | Brian S. Kendig \ Macintosh | Engineering, | bskendig | | Computer Engineering |\ Thought | USS Enterprise | @phoenix.Princeton.EDU | Princeton University |_\ Police | -= NCC-1701-D =- | @PUCC.BITNET | "It's not that I don't have the work to *do* -- I don't do the work I *have*."
a347@mindlink.UUCP (John Miller) (01/23/91)
In message <20283@unix.SRI.COM>, Matthew Mora writes > 1) WHY IN THE WORLD WOULD APPLE WITH ALL THEIR AWESOME PROGRAMMERS > AND UNLIMITED R&D FUNDS CHOOSE TEACH TEXT AS THERE DEFAULT TEXT EDITOR!!!! > THAT IS TRUELY ASSININE! Because it is the only text editor that Apple knows every Mac owner uses. I think TeachText serves its primary function rather well: a small application for reading small "Read Me" files. I'm not so happy with its secondary function: Apple uses it as the example application to teach users how to use Mac programs. An example Mac program that doesn't support Undo? Come on! > Even if they don't add an editor to the finder they should at least > make the default program that it launches configurable. "I'm sorry, > that file is to big for teach text to display" will probably be the > message a user will get if they try to open a big read me file. I suspect one reason that Apple has not made it configurable is they are not sure what to do about the user interface issues. After all, if we're not supposed to let user see evil things like file type signatures and the Finder can't translate the file type into English without access to the Bundle (stored, of course, in the missing application), how does the user specify "Open files of type 'wxyz' with application Y." Of course, the user interface wouldn't have to allow for all file types: many people (???) would be satisfied with a solution that only dealt with text files. There would still be the problem of the user specifying a program that couldn't handle text files: program crashes are so user unfriendly. (Perhaps only allow programs that specify the TEXT type in their bundles ... but even this has problems) ... actually, I guess the Finder translates the creator into English, rather than the file type. Is there no English for the file type? Will the Finder's designers ever allow the file lists to say: "text document" rather than the generic "document"? In any case, this is comp.sys.mac.programmer and we don't have to worry about little details like a lack of user interface. A quick probe with MacsBug and ResEdit reveals that the solution (for version 7.0b1) is the 'fmap' resource with ID 17010 of the Finder: a list of file type and default creator signatures. MPW is now my default for text files. I added an entry that makes MacWrite files open Microsoft Word. The possibilities are endless. (Actually, I only tried that one extra entry ... they may be some limit on the number of entries built into the code.) ---------------------------------------------------------------------- John Miller (604) 433-1795 Symplex Systems AppleLink (rarely) CDA0461 Burnaby, British Columbia Fax: (604) 430-8516 Canada usenet: john_miller@mindlink.uucp ----------------------------------------------------------------------
bin@primate.wisc.edu (Brain in Neutral) (01/24/91)
From article <5611@idunno.Princeton.EDU>, by bskendig@dry.Princeton.EDU (Brian Kendig): > Apple is working towards breaking software apart into little modules > each of which does a specific task. Tacking TeachText or any other Huh. Sounds like UNIX. :-) -- Paul DuBois dubois@primate.wisc.edu
mxmora@unix.SRI.COM (Matt Mora) (01/24/91)
In article <FRANCIS.91Jan22163523@daisy.uchicago.edu> francis@uchicago.edu (Francis Stracke) writes: >Text editors are about the most personality-subject apps around. If >Apple gave us one, lots of us would complain about it. :-) This is true. Apple should at least let us say what editor/wp we want to use to open up a text document. I for one can't stand teach text and its not on my hard disk. >Your word processor really should be easy to find--if your directory >structure makes it hard to find what you need, that's not Apple's >fault. (IMHO and no offense meant. :-) SFGetFile is, I agree, not as >nice as it could be--it would be nice if there were more user control >(e.g., being able to mark a file from the Finder). Boomerang makes it >nicer, but there are a few other things that would be nice. I'm sorry I should have made myself more clear. I'm a consultant here a SRI and I have to go out and fix peoples Mac problems. You would be amazed where people put stuff. I have no problems finding where MY applications are. I have multifinder application and a Fkey that know where my apps are and can launch them for me. Its kind of like _Launch but there is no (practical) limit to the number of applications that it can hold. You just rescan you hard disk whenever you add an application or move one. But I digress... Being a consultant / developer I have to have a lot of applications on my hard disk in case I get a call to help a user. I don't remember where every application is nor do I care to. Its not my job its the Finder's(tm). >| Francis Stracke | My opinions are my own. I don't steal them.| Matt -- ___________________________________________________________ Matthew Mora | my Mac Matt_Mora@QM.SRI.COM SRI International | my SUN mxmora@unix.sri.com ___________________________________________________________
aland@chaos.cs.brandeis.edu (Alan D Danziger) (01/24/91)
In article <20283@unix.SRI.COM> mxmora@unix.SRI.COM (Matt Mora) writes:
1) WHY IN THE WORLD WOULD APPLE WITH ALL THEIR AWESOME PROGRAMMERS
AND UNLIMITED R&D FUNDS CHOOSE TEACH TEXT AS THERE DEFAULT TEXT EDITOR!!!!
THAT IS TRUELY ASSININE!
Well, I accidently deleted more than I wanted to, but...
One feature of System 7 is that you can launch a program and have it
open up a file by dragging that file onto the application and 'letting
go', similar to the way you throw things into the trash. I believe
this feature works with alias's as well (I'll check, and get back if
it doesn't.) What this means is that if you keep a folder of Alias's,
or just, say, Word 4.0 (which is Sys7b1 compatible) or its alias on
the desktop, then you can just drag a file onto it, and they will
open. This basically seems to solve the 'default text editor'
problem.
2) Apple has open up the system file. This is great no more font/da mover.
BUT WHAT ABOUT FKEYS? Come on Apple just a few changes to some source
and you can also drag Fkey files into the system folder. Thats not asking
too much. I don't remember if you can drag sound files but if not you
should include them too.
You can drag in Sound files, but I'm not sure about FKeys.
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Alan D. Danziger, | 753 South St,Waltham MA 02154 | "What a drag,
aland@chaos.cs.brandeis.edu | MB 3130 / Brandeis University | it is,
(617) 894-6859 or 647-3720 | PO Box 9110 Waltham MA 02254 | getting old"
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Alan D. Danziger, | 753 South St,Waltham MA 02154 | "What a drag,
aland@chaos.cs.brandeis.edu | MB 3130 / Brandeis University | it is,
(617) 894-6859 or 647-3720 | PO Box 9110 Waltham MA 02254 | getting old"lsr@Apple.com (Larry Rosenstein) (01/24/91)
In article <5611@idunno.Princeton.EDU>, bskendig@dry.Princeton.EDU (Brian Kendig) writes: > > Isn't that being fixed in System 7.0? Serious question here -- > anyone? If it's not, and even if the dialogs complain something like > "The aplication that created this document can not be found" and exit > instead of offering to open it with another application that can read > TEXT files -- THEN, I'd bash a few fruitcakes at Apple. In the current System 7 release several things are done. If you try to open a TEXT or PICT document and the application isn't found, the Finder will offer to open it with TeachText. It is possible to add a resource to a document that will provide more descriptive information. One such resource identifies the name of the application that created it, so at least the user will know that. A different resource is used for documents that aren't supposed to be opened from the Finder. Also, you can drop documents onto applications in the Finder, provided the application contains an FREF for the document. This means that you can keep an alias to your favorite WP program on the desktop, and drop TEXT files onto it. Someone could write a "universal" viewer that could display large TEXT files, PICTs, ... and use that instead. > having to reach for the mouse to click on the Multifinder icon under > System 6 to switch between my telnet session and my text editor, but > now I have to actually pull down a _menu_? Bleah. I've updated my ApplicationMenu utility to work with System 7. It doesn't provide keyboard switching, but it allows you to popup the menu from anywhere on the screen. I'm still testing it before releasing the "final" version. Larry
rmh@apple.com (Rick Holzgrafe) (01/24/91)
In article <FRANCIS.91Jan22163523@daisy.uchicago.edu> francis@uchicago.edu (Francis Stracke) writes: > Once you found the WP program (after digging through a few folders) you have > to remember wher the file was and hunt for with the lovely SFGet file. Now > > Your word processor really should be easy to find True - and if it is, you can just drag the document icon onto the word processor icon (as if dragging into a folder). The Finder will launch the word processor and tell it to open the document. One gotcha: the app's BNDL has to mention the file type of the document. This makes it worthwhile to stick an alias for your word processor in an easy-to-reach place. I keep a folder named "Favorites" open in a small window at the bottom of my screen (where I used to put things on the desktop, before MultiFinder :-) and keep aliases of frequently-used apps there, ready for either double-clicking or dragging onto. ========================================================================== Rick Holzgrafe | {sun,voder,nsc,mtxinu,dual}!apple!rmh Software Engineer | AppleLink HOLZGRAFE1 rmh@apple.com Apple Computer, Inc. | "All opinions expressed are mine, and do 20525 Mariani Ave. MS: 3-PK | not necessarily represent those of my Cupertino, CA 95014 | employer, Apple Computer Inc."
mystone@mondo.engin.umich.edu (Dean Yu) (01/24/91)
In article <11827@goofy.Apple.COM> lsr@Apple.com (Larry Rosenstein) writes: >In article <5611@idunno.Princeton.EDU>, bskendig@dry.Princeton.EDU (Brian Kendig) writes: >> having to reach for the mouse to click on the Multifinder icon under >> System 6 to switch between my telnet session and my text editor, but >> now I have to actually pull down a _menu_? Bleah. > >I've updated my ApplicationMenu utility to work with System 7. It doesn't >provide keyboard switching, but it allows you to popup the menu from >anywhere on the screen. I'm still testing it before releasing the "final" >version. > I wrote a hack several months ago which puts the twitch back into the MultiFinder icon in System 7. (ie, you can click on the icon to switch applications instead of having to select the application from the menu.) I don't have a copy handy, but it's on the MacHack '90 CD. -- Dean _______________________________________________________________________________ Dean Yu | E-mail: mystone@mondo.engin.umich.edu Patches 'R' Us | Real-mail: Dean Yu A Division of Cyberite Systems | 909 Church St Apt C | Ann Arbor, MI 48104 I'm not the voice of Reason, much | Phone: 313 662-4073 less the voice of Cyberite. | 313 662-4163 -------------------------------------------------------------------------------
stearns@Apple.COM (Bryan Stearns) (01/24/91)
In article <20283@unix.SRI.COM>, mxmora@unix.SRI.COM (Matt Mora) asks a couple of reasonable questions about System 7.0. Because I was involved with both the issues he asks about, I'll stick my neck out and venture an answer (then I'll avoid reading comp.sys.mac.programmer for a month while the flames subside! :-) >1) WHY IN THE WORLD WOULD APPLE WITH ALL THEIR AWESOME PROGRAMMERS > AND UNLIMITED R&D FUNDS CHOOSE TEACH TEXT AS THERE DEFAULT TEXT EDITOR!!!! > THAT IS TRUELY ASSININE! First, thanks for the awesome compliment as well as the minor insult; as the author of TeachText, I can assure you that only trace amounts of our "unlimited R&D funds ever made it into my pocket (boy, if I had a dime for every copy of teachtext, I could buy you all cheesesteaks at Calvin's from now until System 7 ships, and still have several bucks left over!). TeachText IS NOT a word processor. It originally had three design criteria; it now has a fourth. Here they are; they may help you to understand where TeachText fits into the big picture. (1) TeachText is a learning tool; when we stopped shipping MacWrite with every Macintosh, the folks who write our wonderful tutorials needed an example application on which to teach users about the wonders of cut, paste, copy, etc. (Yes, I know, undo is important too, but it was written in a weekend [just to prove to myself that I could] and at the last moment before a System release. It came down to a choice between undo and hiding my friends' names in the About box, and you know which one I picked!) (2) Also for the folks who write our wonderful manuals, it allows users to read ReadMe files, so that we can tell users about things that we didn't know when the manual deadline passed. There's a hack to support pictures in ReadMe files so that our writers can show screen shot fragments, too (but the hack is so evil that it's turned off for non-ReadMe documents). (3) IT DOESN'T COMPETE WITH THIRD-PARTY WORD PROCESSORS. Remember, we just stopped shipping MacWrite because developers were complaining that they couldn't compete with us even though their word processors were superior to the MacWrite of the time. (Parenthetically, this has been great for us users: word processors have gotten much better, due in part to increased competition. Even MacWrite!). (4) New for System 7.0, TeachText allows users to view PICT files. The old mechanism for taking screen shots has been revamped to support multiple monitors and color, so MacPaint documents could no longer be the format of choice. [I had nothing to do with this recent work; my pal Frank Stanbach deserves the credit here!] Others have defended the position that Finder shouldn't have an editor built in, though this was considered. The argument that "if we did build an editor in, it wouldn't be good enough" is strong; that's the key reason behind the new feature where you can drag any document to any app that understands that file type, even if it didn't create the document. >2) Apple has open up the system file. This is great no more font/da mover. > BUT WHAT ABOUT FKEYS? Come on Apple just a few changes to some source > and you can also drag Fkey files into the system folder. Thats not asking > too much. I don't remember if you can drag sound files but if not you should > include them too. > Lots of folks, including myself, wanted to add support for moving FKEYS along with fonts, desk accessories, and, yes, sounds. Ultimately, this idea died because it would have required some new user interface for resolving ID conflicts between FKEYS. Think about it - there really isn't anything new about the addition of Font/DA Mover's functionality to Finder, and we really worked thought hard before bending the new Finder's interface. Besides, Apple doesn't really want to encourage development of FKEYS: they have no user interface themselves, there's not a defined environment for them to run in, this can lead to compatibility problems later, etc. My personal feeling, here in my asbestos suit, is that users are better off with a CEToolbox-style mechanism for invoking DAs, etc, but that isn't necessarily Apple's opinion. ..................................................................... Bryan Stearns Apple Computer, Inc. stearns@apple.com 20525 Mariani Avenue, M/S 81-BB Cupertino, CA 95014
bskendig@phoenix.Princeton.EDU (Brian Kendig) (01/24/91)
In article <11827@goofy.Apple.COM> lsr@Apple.com (Larry Rosenstein) writes: >In article <5611@idunno.Princeton.EDU>, bskendig@dry.Princeton.EDU (Brian Kendig) writes: >Also, you can drop documents onto applications in the Finder, provided the >application contains an FREF for the document. This means that you can >keep an alias to your favorite WP program on the desktop, and drop TEXT files >onto it. Someone could write a "universal" viewer that could display large >TEXT files, PICTs, ... and use that instead. Hmm. Can I just hilite the files I want to open from the Finder, then select the word processor or other program I want to open them with from the Apple menu? I *hate* keeping things laying out on my little Mac SE screen. It clutters up far too quickly. << Brian >> | Brian S. Kendig \ Macintosh | Engineering, | bskendig | | Computer Engineering |\ Thought | USS Enterprise | @phoenix.Princeton.EDU | Princeton University |_\ Police | -= NCC-1701-D =- | @PUCC.BITNET | "It's not that I don't have the work to *do* -- I don't do the work I *have*."
olson@bootsie.uucp (Eric K. Olson) (01/24/91)
In many articles, many people discuss possible shortcomings of System 7 including the use of TeachText as the default 'TEXT' editor... Does anybody know where the signature 'ttxt' is stored? I would expect it to be configurable. If you change the creator of your favorite editor to 'ttxt', I would expect it to become the default editor. I'll bet it even gets the name right in the dialog! -Eric -- Eric K. Olson, Editor, Prepare() NOTE: olson@bootsie.uucp doesn't work Lexington Software Design Internet: olson@endor.harvard.edu 72A Lowell St., Lexington, MA 02173 Uucp: harvard!endor!olson (617) 863-9624 Bitnet: OLSON@HARVARD
Greg@AppleLink.Apple.Com (Greg Marriott) (01/24/91)
In article <20320@unix.SRI.COM>, mxmora@unix.SRI.COM (Matt Mora) writes: > Being a consultant / developer I have to have a lot of applications on > my hard disk in case I get a call to help a user. I don't remember where > every application is nor do I care to. Its not my job its the Finder's(tm). > You're absolutely right, it's the Finder's job. That's why we added the Find feature to the 7.0 Finder. (Wow! The Finder is finally a FINDER! :) You don't have to go "folder hunting" any more... just ask the Finder! Greg Marriott Blue Meanie Apple Computer, Inc.
bskendig@dry.Princeton.EDU (Brian Kendig) (01/25/91)
In article <11827@goofy.Apple.COM> lsr@Apple.com (Larry Rosenstein) writes: >In article <5611@idunno.Princeton.EDU>, bskendig@dry.Princeton.EDU (Brian Kendig) writes: >> Isn't that being fixed in System 7.0? Serious question here -- >> anyone? If it's not, and even if the dialogs complain something like >> "The aplication that created this document can not be found" and exit >> instead of offering to open it with another application that can read >> TEXT files -- THEN, I'd bash a few fruitcakes at Apple. > >In the current System 7 release several things are done. If you try to open >a TEXT or PICT document and the application isn't found, the Finder will >offer to open it with TeachText. And if I try to open, say, a MacWrite document, there is a built-in way to tell the Mac to open it with Microsoft Word, right? I mean, it's certainly not going to tell me the obvious that it can't find MacWrite, is it? >It is possible to add a resource to a document that will provide more >descriptive information. One such resource identifies the name of the >application that created it, so at least the user will know that. A >different resource is used for documents that aren't supposed to be opened >from the Finder. Will the Finder be smart enough to add a resource to, say, the Desktop file to record that all MPNT (or whatever the creator code is) files are created by MacPaint? And what good is this information, save for seeing "MacPaint document" in the directory window, unless it knows that I want to open all MacPaint documents with SuperPaint instead? It just bothers me that the method of finding an application to open a document should be handled a wee bit more thoroughly -- especiall now that practically any word processor can open a file from practically any other word processor. Same with paint programs, and spreadsheets, and everything else... << Brian >> | Brian S. Kendig \ Macintosh | Engineering, | bskendig | | Computer Engineering |\ Thought | USS Enterprise | @phoenix.Princeton.EDU | Princeton University |_\ Police | -= NCC-1701-D =- | @PUCC.BITNET | "It's not that I don't have the work to *do* -- I don't do the work I *have*."
mxmora@unix.SRI.COM (Matt Mora) (01/25/91)
In article <11831@goofy.Apple.COM> stearns@Apple.COM (Bryan Stearns) writes: >In article <20283@unix.SRI.COM>, mxmora@unix.SRI.COM (Matt Mora) > >>1) WHY IN THE WORLD WOULD APPLE WITH ALL THEIR AWESOME PROGRAMMERS >> AND UNLIMITED R&D FUNDS CHOOSE TEACH TEXT AS THERE DEFAULT TEXT EDITOR!!!! >> THAT IS TRUELY ASSININE! I would like to retract that statement (except the part that says Apple has awesome programmers) and apologize if I have insulted anyone. I guess I should't have said anything until I read all the documentation on system 7.0. (gee I thought this was a Mac OS and I didn't have to read manuals. How silly of me! :-)) Before I posted the first message I did do a fast search of the finder with resedit to see if I could find the teach text signature. I forgot that all Mac users have macsbug and resedit so that they can find the resource and modify it to point to the word processor/editor of their choice. :-) What would be wrong with a finder preferences dialog that the user can select the default application for editing a plain text file. Of course this would be by default set to teach text. >buy you all cheesesteaks at Calvin's from now until System 7 ships, >and still have several bucks left over!). Brian if you want I'll buy you a cheesesteak at Calvin's. Just let me know the time and how to get there from Menlo Park. I have nothing against teach text, I just perfer not to use it. Oh, by the way how come teach text version 7 only runs with system 7.0? Isn't that a no no. Aren't you supposed to ask the system what version it is running and go from there? What could be so different in teach text that it no longer works with system 6.0.7? If the system doesn't have a a certian functionality you want aren't you supposed not offer that function in your appplication and continue working? >Others have defended the position that Finder shouldn't have an >editor built in, though this was considered. The argument that "if >we did build an editor in, it wouldn't be good enough" is strong; >that's the key reason behind the new feature where you can drag >any document to any app that understands that file type, even if >it didn't create the document. That's a great feature. But what is going to happen when Apple includes Apple Scripts? Are they going to be edited in teach text if the user doesn't have an editor? >Lots of folks, including myself, wanted to add support for moving FKEYS >along with fonts, desk accessories, and, yes, sounds. Ultimately, this >idea died because it would have required some new user interface for >resolving ID conflicts between FKEYS. Think about it - there really >isn't anything new about the addition of Font/DA Mover's functionality >to Finder, and we really worked thought hard before bending the new >Finder's interface. "A new user interface"? since when is Apple afraid inventing something new? If Apple doesn't want to expand the user interface maybe its time to start looking for a used NeXT. :-) The interface to me seems trival. In the system file would be an FKEY icon. The user could either double click to open the icon or drag a fkey file on to it. If the user opens it, she would see a window with a picture of the keyboard attached to her system.The user could then drag a FKEY icon in to the FKEY slot that they wanted to execute the FKEY. No id conflicts. The FKEY file could be extended to include a bundle resource so that the fkey could have a unique icon. You could even have a FKEY holding area in the system so the user could drag in and out of a FKEY slot less used FKEY's. -------------------------------------------------- | F1 F2 F3 F4 F5 F6 \ | ---- ---- ---- ---- ---- ---- / | | | | | | | | | | | | | <---- Fkeys can be placed | | | | | | | | | | | | | in one of these slots | ---- ---- ---- ---- ---- ---- \ | | ------------------------------------------------- | | |^ | | | |--| | | | | | | Holding area |__| | | |||| | | FKEYS are given a unique id when |--| | | Placed in here. | | | | |--| | | |V | | ------------------------------------------------ ------------------------------------------------------ If the user just drags a FKEY file onto the FKEY icon in the system then it could be placed into the holding area. >Besides, Apple doesn't really want to encourage development of >FKEYS: they have no user interface themselves, there's not a defined >environment for them to run in, this can lead to compatibility >problems later, etc. My personal feeling, here in my asbestos >suit, is that users are better off with a CEToolbox-style mechanism >for invoking DAs, etc, but that isn't necessarily Apple's opinion. Oh I see, Apple is more keen on delevoping INIT's and CDEV's. All those wonderfull things patching traps and mucking with getnextevent. No compatability problems there! I would much rather use a FKEY to get something done. They don't take up any memory in the system heap, they don't slow down processing checking to see if they have been invoked and I guess that they don't patch traps. It seems that they are more compatible than an INIT (IMHO). Yes I know an FKEY can't do everything. I think Apple drop the ball on fkeys and that they should extend the user interface to include them. Most FKEYS can have a user interface if they were given owned resources like DA's and CDEV's. > ..................................................................... >Bryan Stearns Apple Computer, Inc. Matt -- ___________________________________________________________ Matthew Mora | my Mac Matt_Mora@QM.SRI.COM SRI International | my SUN mxmora@unix.sri.com ___________________________________________________________
jln@casbah.acns.nwu.edu (John Norstad) (01/25/91)
In article <3810@uakari.primate.wisc.edu> bin@primate.wisc.edu (Paul DuBois = Brain in Neutral) writes: > From article <5611@idunno.Princeton.EDU>, by bskendig@dry.Princeton.EDU (Brian Kendig): > > Apple is working towards breaking software apart into little modules > > each of which does a specific task. Tacking TeachText or any other > > Huh. Sounds like UNIX. :-) Yes, it's just like UNIX, only completely different :-) Permit me to mount my soapbox... In UNIX, software pieces are combined using a procedural scripting language. Command line parameters are used to control the operation of each piece, and typically the pieces communicate with each other by "piping" the output of one piece into the input of another piece. In System 7.0, software pieces communicate using an object-oriented message passing system called "AppleEvents." This is a much more sophisticated and powerful architecture than you'll find in vanilla UNIX systems. Eventually, if all goes well, we hope to see an object-oriented system-wide scripting language based on HyperTalk and AppleEvents which can be used to control this process. System 7.0 will not include this scripting language, but it lays the foundation for such a language. This is another example of how Apple takes "old" ideas and "reinvents" them in the context of the modern world of personal computers and direct manipulation human interfaces. The new "aliases" in System 7.0 are another example - the old idea of "links" improved and expanded. Apple's approach to networking over the years is another good example. IMHO, this is much more interesting, exciting, and important work than simply tacking "GUIs" on top of traditional command-line systems, e.g., X and NextStep on top of UNIX and Windows 3.0 on top of DOS. John Norstad Academic Computing and Network Services Northwestern University jln@casbah.acns.nwu.edu
lsr@Apple.com (Larry Rosenstein) (01/25/91)
In article <5647@idunno.Princeton.EDU>, bskendig@phoenix.Princeton.EDU (Brian Kendig) writes: > > Hmm. Can I just hilite the files I want to open from the Finder, then > select the word processor or other program I want to open them with > from the Apple menu? I don't think so. Selecting an item from the Apple menu is supposed to be equivalent to selecting the corresponding icon and then the Open item in the Finder. One thing that might be possible is to write a universal document handler onto which you could drop a variety of documents. This app would figure out which application you wanted to handle the document and launch that application. That way you would only need one icon on the desktop.
dorner@pequod.cso.uiuc.edu (Steve Dorner) (01/25/91)
In article <2899@casbah.acns.nwu.edu> jln@casbah.acns.nwu.edu (John Norstad) writes: >This is another example of how Apple takes "old" ideas and "reinvents" >them in the context of the modern world of personal computers and direct >manipulation human interfaces. ... Apple's >approach to networking over the years is another good example. Bad, bad example. I think Apple BLEW IT on AppleTalk. The only interesting idea they had was the plug-and-play nature of the thing. The protocol itself is horrendously myopic; it just won't scale to large internetworks. That's why they've patched in Phase 2. Even the hardware was bad; nobody in their right mind uses real LocalTalk, because the cable is expensive and the connectors fall out. PhoneNet is cheaper, more reliable, and has fewer distance/topology limitations. I remember seeing a photo of a part of Apple's network in MacWorld. Multiple FastPaths on an ethernet, with *PhoneNet* connectors and phone wires going off them. Not an Apple-labelled product in sight. I think Apple is catching up in networking, not leading the pack. >IMHO, this is much more interesting, exciting, and important work than >simply tacking "GUIs" on top of traditional command-line systems, e.g., X >and NextStep on top of UNIX and Windows 3.0 on top of DOS. I think you are missing something VERY fundamental. The Macintosh is a GUI without an operating system. Raw UNIX is an operating system without a GUI. Modern systems will need *both*. Apple is currently reinventing the operating system part; the UNIX vendors are trying their hands at the GUI. Apple has a lot of problems in their task; making the Mac OS a real operating system (with VM, memory protection, preemptive multitasking, and a filesystem that doesn't drive you batty) isn't going to be easy. The UNIX vendors are in a much better position. There is nothing about UNIX which makes a good GUI hard to do; they have the freedom to solve the GUI problems correctly. Some of the UNIX GUI's are dismal, laughable failures (eg, SunTools). Others are arguably as good or better than the Macintosh (eg, NextStep). There is nothing keeping these based-on-UNIX GUI's from being sophisticated GUI's with object-oriented message passing systems (that's what NextStep is). In fact, with the operating system problems out of the way, the UNIX vendors can spend more time on the GUI than Apple, who's still figuring out how to do virtual memory! -- Steve Dorner, U of Illinois Computing Services Office Internet: s-dorner@uiuc.edu UUCP: uunet!uiucuxc!uiuc.edu!s-dorner
lsr@Apple.com (Larry Rosenstein) (01/25/91)
In article <5659@idunno.Princeton.EDU>, bskendig@dry.Princeton.EDU (Brian Kendig) writes: > > And if I try to open, say, a MacWrite document, there is a built-in > way to tell the Mac to open it with Microsoft Word, right? I mean, > it's certainly not going to tell me the obvious that it can't find > MacWrite, is it? If you change the magic resource, then the Finder will put up an alert asking if it's OK to substitute the alternative application. This might be desirable, if you open something unintentionally, or if the application is on removable media/file server where it might be available sometimes. If Word were to add an FREF resource for MacWrite documents, then you could drop a MacWrite document onto the Word app (or an alias). I too wanted to implement a way to bypass the alert, for cases like Illustrator 3.0 which has a different signature than Illustrator 88. My first try was to add an entry to the Desktop DB (to use your example) for MacWrite's signature but refer to the Word application. The Finder would look up the application to use and launch Word instead of MacWrite. (In my case, I patched the call that looks up information in the DB and switched signatures there.) This all worked fine in most cases. The MacWrite documents would even be identified as Word documents. (You could also add icons for the MacWrite documents.) The problem is that if Word was already running, then double clicking a MacWrite document wouldn't work. The problem seemed to be that there was no running app with MacWrite's signature, but the Word file was busy and couldn't be launched. > Will the Finder be smart enough to add a resource to, say, the Desktop > file to record that all MPNT (or whatever the creator code is) files > are created by MacPaint? And what good is this information, save for > seeing "MacPaint document" in the directory window, unless it knows > that I want to open all MacPaint documents with SuperPaint instead? I don't think the Finder will add stuff like this to the Desktop DB. I think you would need some kind of user confirmation that you want to do this, and then the problem is turning it off if you later get a copy of MacPaint. There are significant user interface issue that would have to be addressed. > It just bothers me that the method of finding an application to open a > document should be handled a wee bit more thoroughly -- especiall now I think the current mechanism works well for the average user. The Finder tells you what's happening and doesn't do anything behind your back. The are some hooks in the system for a hacker to change things (perhaps not all the hooks one would like, but I think you can still do a lot of stuff). Larry
bskendig@phoenix.Princeton.EDU (Brian Kendig) (01/25/91)
In article <11848@goofy.Apple.COM> lsr@Apple.com (Larry Rosenstein) writes: >In article <5659@idunno.Princeton.EDU>, bskendig@dry.Princeton.EDU (Brian Kendig) writes: >> It just bothers me that the method of finding an application to open a >> document should be handled a wee bit more thoroughly -- especiall now > >I think the current mechanism works well for the average user. The >Finder tells you what's happening and doesn't do anything behind your >back. The are some hooks in the system for a hacker to change things >(perhaps not all the hooks one would like, but I think you can still do a >lot of stuff). Problem is -- and I'm a consultant here at my school, so I witness this a lot -- a user will have a copy of Word that he's been told will open this MacWrite file he has, so he double-clicks the MacWrite file... and is told that "the application is busy or missing." As I seem to gather from what I've been told about System 7, the Mac will _still_ complain that an application couldn't be found for that document, and will leave it at that. (Someone mentioned that the most the Finder will do now is to suggest that TeachText be used for plain text and PICT files, and no more.) (Of course _you_ know that the person could just open Word then load the file from there, and _I_ know that, but I've found that people assume that if the Finder says they can't load it, then they can't load it at all.) My point is that the Finder has all the important information (that the file is a MacWrite file, and Word can read MacWrite files), but it doesn't bother to look to see that Word can be used. Doing something behind the user's back? If he double-clicked on the file, he most likely wanted to open it, and when the file brings up an error dialog rather that being opened, the user thinks there's something funky happening -- that's not the *intuitive* response. At the very least, have it bring up an SFGetFile dialog: "An application for this document could not be found. Choose another application to open it with." ... and, optionally, remember this selection for later. As for the hooks: Why make it so that only hackers can tinker with the resources to change the default applications? Remember when you used to have to fiddle with the LAYO resource to make your desktop prettier, and see how Apple now made that into a cdev? Why not make an `applications' cdev in which you can specify what will load text files, pictures, soundfiles, spreadsheets, or any other type of file you choose? It'll ask you to pick an example file (you'd pick a MacPaint graphic), then it asks you what application you will want to use to open it as a default (you'd pick SuperPaint, for example). I know I'm picking a fine point to death, but it seems that too little is being done about it. Why is it that I can select twenty files that look like pieces of paper (and just happen to have been made by Word) and load them all into Word with a double-click, but to see these twenty other files that look like pieces of paper (and just happen to have been made by MacWrite), I have to select "Open...", scroll down to the right name, and double-click twenty times? (Which, of course, raises a case for multiple selections in Standard File dialogs that I won't even get into right now. ;) Apple, is there a good reason why you didn't go this far? Is it something you'll consider for System 8? << Brian >> | Brian S. Kendig \ Macintosh | Engineering, | bskendig | | Computer Engineering |\ Thought | USS Enterprise | @phoenix.Princeton.EDU | Princeton University |_\ Police | -= NCC-1701-D =- | @PUCC.BITNET | "It's not that I don't have the work to *do* -- I don't do the work I *have*."
ldo@waikato.ac.nz (Lawrence D'Oliveiro, Waikato University) (01/25/91)
In article <2899@casbah.acns.nwu.edu>, jln@casbah.acns.nwu.edu
(John Norstad) says:
'[taking "old" ideas and "reinventing" them in the context of
modern PCs and direct-manipulation interfaces] is much more
interesting, exciting, and important work than simply tacking
"GUIs" on top of traditional command-line systems, e.g., X
and NextStep on top of UNIX and Windows 3.0 on top of DOS.'
Amen!
Amen!
Amen!
Lawrence D'Oliveiro fone: +64-71-562-889
Computer Services Dept fax: +64-71-384-066
University of Waikato electric mail: ldo@waikato.ac.nz
Hamilton, New Zealand 37^ 47' 26" S, 175^ 19' 7" E, GMT+13:00ldo@waikato.ac.nz (Lawrence D'Oliveiro, Waikato University) (01/25/91)
In article <1991Jan24.224108.19413@ux1.cso.uiuc.edu>,
dorner@pequod.cso.uiuc.edu (Steve Dorner) has a few things
to say about AppleTalk and the Macintosh system:
"I think Apple BLEW IT on AppleTalk.
"The only interesting idea they had was the plug-and-play nature of the
thing."
No, there are *two* interesting ideas, as far as I'm concerned: dynamic
node address assignment (the single major reason for the plug-and-play
nature), and transaction-based protocols. See pages I-14 to I-15 of
Inside AppleTalk, 2nd Ed.
"The protocol itself is horrendously myopic; it just won't scale to
large internetworks. That's why they've patched in Phase 2."
AppleTalk is a great local-area networking system (better with Phase 2),
lousy on wide-area networking, agreed. TCP/IP is a fairly good, very
well understood wide-area networking system, a real headache in a local-area
network. What network protocols do you know of that work well in both
situations? Are they available today?
"Even the hardware was bad; nobody in their right mind uses real LocalTalk,
because the cable is expensive and the connectors fall out. PhoneNet is
cheaper, more reliable, and has fewer distance/topology limitations."
Ding! You've just proven that AppleTalk is properly designed after all!
If it wasn't, you wouldn't have such a choice of different physical
media.
Even the ease with which you can replace LocalTalk cabling with
PhoneNet tells you something about the design of that particular
data-link layer...
"... Macintosh is a GUI without an operating system."
Rubbish.
Note: talking about the design of an operating system is meaningless
unless you keep in mind the needs of actual applications. Macintosh
is not an operating system like traditional ones running on time-shared
machines. But then, the applications that run under it are not like the
traditional ones developed for time-shared systems.
Yes, Macintosh needs preemptive multi-tasking. But I would assert
that the claimed benefits of memory protection and virtual memory are
*overrated*.
Lawrence D'Oliveiro fone: +64-71-562-889
Computer Services Dept fax: +64-71-384-066
University of Waikato electric mail: ldo@waikato.ac.nz
Hamilton, New Zealand 37^ 47' 26" S, 175^ 19' 7" E, GMT+13:00hodas@saul.cis.upenn.edu (Josh Hodas) (01/25/91)
In article <5691@idunno.Princeton.EDU> bskendig@phoenix.Princeton.EDU (Brian Kendig) writes: ... [lots of current argument deleted] > >My point is that the Finder has all the important information (that >the file is a MacWrite file, and Word can read MacWrite files), but it >doesn't bother to look to see that Word can be used. Since when does the finder know that Word is capable of opening a MacWrite file? I didn't know they had built a universal code analyzer into the System 7 finder :-). Now, one option that would solve this is to have a new BNDL like resource in the Application which lists all the file/creator pairs an app can open. The finder could cache this info just as it does icons. Of course the problem then is how to resolve conflicts when multiple apps can open the document. Also, this gets complicated when the ability to open a file type is an external feature (ala Claris XTND's) rather than built into the app itself. Josh ---------------------------------------------------------------------------- Josh Hodas Home Phone: (215) 222-7112 4223 Pine Street School Office Phone: (215) 898-9514 Philadelphia, PA 19104 New E-Mail Address: hodas@saul.cis.upenn.edu
jln@casbah.acns.nwu.edu (John Norstad) (01/26/91)
In article <1991Jan24.224108.19413@ux1.cso.uiuc.edu> dorner@pequod.cso.uiuc.edu (Steve Dorner) writes: > Bad, bad example. I think Apple BLEW IT on AppleTalk. > > The only interesting idea they had was the plug-and-play nature of the > thing. The protocol itself is horrendously myopic; it just won't scale to > large internetworks. That's why they've patched in Phase 2. Hi Steve! In addition to plug-and-play (a MAJOR innovation), I would add NBP. I don't find the protocol myopic at all. It's just about as myopic as TCP/IP as far as I can tell. In fact, they are very similar in many ways (e.g., RTMP almost = RIP, DDP almost = UDP, ADSP almost = TCP, etc.) Everybody agrees that AppleTalk doesn't scale up well to large internets. It was unfortunately not designed with this possibility in mind - a major mistake. Phase 2 does nothing significant to address this problem. There's an Internet Engineering Task Force working on the large internet problem. For example, they're working on protocols so that separate AppleTalk internets can join together into a larger combined internet without having to worry about network number conflicts. > I think Apple is catching up in networking, not leading the pack. I would never call AppleTalk perfect, but it was indeed a major innovation and a tremendous success. I'd say that Apple is helping to lead the pack. > >IMHO, this is much more interesting, exciting, and important work than > >simply tacking "GUIs" on top of traditional command-line systems, e.g., X > >and NextStep on top of UNIX and Windows 3.0 on top of DOS. > > I think you are missing something VERY fundamental. The Macintosh is > a GUI without an operating system. Raw UNIX is an operating system without > a GUI. Modern systems will need *both*. The Mac does indeed have an operating system - it has a file system, a memory management system, and a process scheduling system. It was designed for personal computers rather than for traditional multiuser timesharing systems. Yes, it's very different from those systems, and yes, it has alot of growing up to do, and yes, it could learn a number of very important lessons from it's big brothers. The difference is that Apple has started over from the ground up. They are rethinking traditional timesharing operating system concepts and redesigning them in very significant ways within the context of the direct manipulation graphical interface on a personal computer. This takes a long time, and it will take many more years of hard work and lots of luck before we see the Mac OS, or more likely some successor to the Mac OS, become really mature. > Apple is currently reinventing the operating system part; the UNIX vendors > are trying their hands at the GUI. > > Apple has a lot of problems in their task; making the Mac OS a real operating > system (with VM, memory protection, preemptive multitasking, and a filesystem > that doesn't drive you batty) isn't going to be easy. Yes, this is all true, and in fact it may be impossible to extend the current Mac OS to include all this good stuff. It seems likely to me that at some point in the not too distant future Apple is going to have to abandon the current OS and start over from scratch with a successor OS. > The UNIX vendors are in a much better position. There is nothing about > UNIX which makes a good GUI hard to do; they have the freedom to solve > the GUI problems correctly. Some of the UNIX GUI's are dismal, laughable > failures (eg, SunTools). Others are arguably as good or better than the > Macintosh (eg, NextStep). > > There is nothing keeping these based-on-UNIX GUI's from being sophisticated > GUI's with object-oriented message passing systems (that's what NextStep is). Here's where we have a fundamental disagreement. I don't think that the UNIX OS is a suitable platform for personal computers, no matter how many human interface "layers" you patch on top of it. Personal computers in my opinion are radically different in a very fundamental sense from traditional multiuser timesharing systems, and they require new operating system concepts and designs, not just new GUIs on top of old operating system concepts and designs. UNIX is the very best of the old tradition, and people involved in the design of new systems would be crazy not to study it carefully and learn from it. But we need something completely new for the future of computing. What I like about Apple is that they continue to have the guts to tackle this very difficult problem. I agree, however, that NeXT is doing interesting things, and it's the only "GUI on top of UNIX" which I take seriously. I wish I could figure out how I manage to get sucked up into these USENET arguments every few months. I really should be doing some real work today :-) ... John Norstad Academic Computing and Network Services Northwestern University jln@casbah.acns.nwu.edu
jln@casbah.acns.nwu.edu (John Norstad) (01/26/91)
In article <1991Jan24.224108.19413@ux1.cso.uiuc.edu> dorner@pequod.cso.uiuc.edu (Steve Dorner) writes: > Apple has a lot of problems in their task; ... and a filesystem > that doesn't drive you batty) ... Apple has cleaned up the file system quite a bit in 7.0. There are new high-level File Manger routines which use "FSSpec" records to identify files. An FSSPec record identifies a file by it's volume reference number, directory id, and file name. I've been working with these calls lately, and they really are a major improvement. The big problem is that the new calls only work under System 7.0, and they only work with HFS volumes. One of the things I've been working on is a "glue" module that will make them work on all systems, even old 64K ROM systems, and with MFS volumes. John Norstad Academic Computing and Network Services Northwestern University jln@casbah.acns.nwu.edu
lsr@Apple.com (Larry Rosenstein) (01/26/91)
In article <5691@idunno.Princeton.EDU>, bskendig@phoenix.Princeton.EDU (Brian Kendig) writes: > > open this MacWrite file he has, so he double-clicks the MacWrite > file... and is told that "the application is busy or missing." As I > My point is that the Finder has all the important information (that > the file is a MacWrite file, and Word can read MacWrite files), but it You are right in general, but in this particular case, I don't think the Finder knows that Word can read MacWrite files. (Word doesn't contain an FREF for MacWrite files.) > rather that being opened, the user thinks there's something funky > happening -- that's not the *intuitive* response. At the very least, The dialog has been improved in System 7. (There are options for a document to identify what application created it.) > have it bring up an SFGetFile dialog: "An application for this > document could not be found. Choose another application to open it > with." ... and, optionally, remember this selection for later. Again, you can't always tell what application can open a document. > As for the hooks: Why make it so that only hackers can tinker with the > resources to change the default applications? Remember when you used It keeps hackers off the streets. :-) Putting these things into resources gives 3rd parties the opportunity to fill a need. It would be nice if Apple could build this stuff in, but there's only so much engineering, documentation, UI, talent available and tradeoffs have to be made. > an `applications' cdev in which you can specify what will load text Adding features such as this is rarely as easy as it seems. But if you're interested, you can implement this cdev and interface it to the extension that I have already to make this easier to configure. > Apple, is there a good reason why you didn't go this far? Is it > something you'll consider for System 8? I know that lots of neat features fall by the wayside because they turn out to be too complicated to implement, or don't work well in user testing, or end up being lower in priority than other features. It's certainly worthwhile to make these kind of suggestions, because they might make it into a system someday.
ech@cbnewsk.att.com (ned.horvath) (01/27/91)
From article <11863@goofy.Apple.COM>, by lsr@Apple.com (Larry Rosenstein): > Putting these things into resources gives 3rd parties the opportunity to > fill a need. It would be nice if Apple could build this stuff in, but > there's only so much engineering, documentation, UI, talent available and > tradeoffs have to be made. OK, I missed the beginning of this thread, but it looks to me like the "magic cookie" mapping orphaned TEXT and PICT to ttxt (TeachText) is 'fmap' 17010 in the 7.0b1 Finder. Notice that there is, in general, no way to gain write access to that resource in a running 7.0 system -- the resource fork is, uh, busy. The System file would be better, and a small file, or better, an AppleEvent to "Register" or "unregister" the foster parent would be better still. Larry, I appreciate that not EVERYTHING can go in. But I'll suggest that the "foster application" idea is a nice thing that ought to be done thoroughly before one of us cooks up some horrendous hack... =Ned Horvath= ehorvath@attmail.com
freek@fwi.uva.nl (Freek Wiedijk) (01/28/91)
jln@casbah.acns.nwu.edu (John Norstad) writes: > I don't think that the >UNIX OS is a suitable platform for personal computers, no matter how many >human interface "layers" you patch on top of it. Right! The concept of a "super user" is ridiculous! Freek "the Pistol Major" Wiedijk E-mail: freek@fwi.uva.nl #P:+/ = #+/P?*+/ = i<<*+/P?*+/ = +/i<<**P?*+/ = +/(i<<*P?)*+/ = +/+/(i<<*P?)**
keith@Apple.COM (Keith Rollin) (01/29/91)
In article <2939@casbah.acns.nwu.edu> jln@casbah.acns.nwu.edu (John Norstad) writes: >In article <1991Jan24.224108.19413@ux1.cso.uiuc.edu> >dorner@pequod.cso.uiuc.edu (Steve Dorner) writes: >> Apple has a lot of problems in their task; ... and a filesystem >> that doesn't drive you batty) ... > >Apple has cleaned up the file system quite a bit in 7.0. There are new >high-level File Manger routines which use "FSSpec" records to identify >files. An FSSPec record identifies a file by it's volume reference >number, directory id, and file name. I've been working with these calls >lately, and they really are a major improvement. > >The big problem is that the new calls only work under System 7.0, and they >only work with HFS volumes. One of the things I've been working on is a >"glue" module that will make them work on all systems, even old 64K ROM >systems, and with MFS volumes. I just got out of a File Manager Chapter review meeting where I found out that the FSpXXX calls will work on MFS volumes. However, you can still only call them from System 7.0. -- ------------------------------------------------------------------------------ Keith Rollin --- Apple Computer, Inc. --- Developer Technical Support INTERNET: keith@apple.com UUCP: {decwrl, hoptoad, nsc, sun, amdahl}!apple!keith "Argue for your Apple, and sure enough, it's yours" - Keith Rollin, Contusions
lsr@Apple.com (Larry Rosenstein) (01/29/91)
In article <1991Jan26.221219.4169@cbnewsk.att.com>, ech@cbnewsk.att.com (ned.horvath) writes: > > Larry, I appreciate that not EVERYTHING can go in. But I'll suggest that > the "foster application" idea is a nice thing that ought to be done > thoroughly before one of us cooks up some horrendous hack... Too late. I've got the hack already. I don't think it make sense to put this resource in the System file; should any app be able to add to the System file? It belongs in the Finder, and ideally there would be a mechanism to change the resource from within the Finder.
ech@cbnewsk.att.com (ned.horvath) (01/30/91)
I said, > Larry, I appreciate that not EVERYTHING can go in. But I'll suggest that > the "foster application" idea is a nice thing that ought to be done > thoroughly before one of us cooks up some horrendous hack... From article <11886@goofy.Apple.COM>, by lsr@Apple.com (Larry Rosenstein): > Too late. I've got the hack already. > > I don't think it make sense to put this resource in the System file; > should any app be able to add to the System file? It belongs in the Finder, > and ideally there would be a mechanism to change the resource from > within the Finder. Sounds good. That's why I suggested an AppleEvent. =Ned=
kent@lloyd.camex.com (Kent Borg) (02/01/91)
In article <1991Jan26.221219.4169@cbnewsk.att.com> ech@cbnewsk.att.com (ned.horvath) (and others) write(s):
about 7.0 Finder launching "foster applications" to open "orphan
documents". (Like Word opening a MacWrite document)
I think I would like it if, when an orphan document is opened, Finder
presents the user with a list of applications that are on mounted
disks and mention that document type in their bundles. The user
selects the desired application and Finder tells it to open the
document.
Clearly, if the real application later shows up, Finder should ask
*it* to open the document.
A nice aditional feature would be if Finder remembered what foster
application was chosen last time and moved it to the head of the list,
selected, and waiting for a Return or Enter to continue.
Reasonable?
--
Kent Borg internet: kent@camex.com AOL: kent borg
H:(617) 776-6899 W:(617) 426-3577
Kent's Invasion Countdown: I was off by 24-hours.bell@pyro.ei.dupont.com (Mike Bell) (02/01/91)
In article <1766@camex.COM> kent@camex.com (Kent Borg) writes: >In article <1991Jan26.221219.4169@cbnewsk.att.com> ech@cbnewsk.att.com (ned.horvath) (and others) write(s): > about 7.0 Finder launching "foster applications" to open "orphan >documents". (Like Word opening a MacWrite document) > > >I think I would like it if, when an orphan document is opened, Finder >presents the user with a list of applications that are on mounted >disks and mention that document type in their bundles. The user >selects the desired application and Finder tells it to open the >document. > >Clearly, if the real application later shows up, Finder should ask >*it* to open the document. > >A nice aditional feature would be if Finder remembered what foster >application was chosen last time and moved it to the head of the list, >selected, and waiting for a Return or Enter to continue. > >Reasonable? > > >-- >Kent Borg internet: kent@camex.com AOL: kent borg > H:(617) 776-6899 W:(617) 426-3577 >Kent's Invasion Countdown: I was off by 24-hours. The control panel device Handoff II written by Fred Hollander does something very similar. I have gotten so used to it, that I sometimes forget that it isn't part of the system software. I highly reccommend it. Mike Bell -- ******************************************************************************** Mike Bell Internet: bell@opus.wizards.dupont.com Senior Engineer CSNet: BELLMA%ESVAX@dupont.com DuPont CR&D Applelink: D2747 Advanced Computer Technology Group MacBLITZ..... When you feel the need for speed.......... ******************************************************************************** --
bskendig@dry.Princeton.EDU (Brian Kendig) (02/02/91)
In article <ALAND.91Jan31172038@chaos.cs.brandeis.edu> aland@chaos.cs.brandeis.edu (Alan D Danziger) writes: >In article <11886@goofy.Apple.COM> lsr@Apple.com (Larry Rosenstein) writes: >[in reference to Sys7's ability to offer TeachText for a PICT or TEXT >file and the customability of this 'forwarding'] > I don't think it make sense to put this resource in the System file; > should any app be able to add to the System file? It belongs in the > Finder, and ideally there would be a mechanism to change the resource > from within the Finder. > >Actually, I think this should be a separate file, similar to the >desktop file, in which you could have all sorts of cross-linking >pointers (type/creators)--Since the file (resource file) is not 'part' >of the finder or the System, you would not have to limit the number of >cross references which were used... Sounds like a job for the Finder Preferences file! Just keep a list of which applications should deal with what file types when the creator of a file can't be found, and let this be configurable through the control panel... << Brian >> | Brian S. Kendig \ Macintosh | Engineering, | bskendig | | Computer Engineering |\ Thought | USS Enterprise | @phoenix.Princeton.EDU | Princeton University |_\ Police | -= NCC-1701-D =- | @PUCC.BITNET | "It's not that I don't have the work to *do* -- I don't do the work I *have*."
jtn@potomac.ads.com (John T. Nelson) (02/02/91)
>My point is that the Finder has all the important information (that >the file is a MacWrite file, and Word can read MacWrite files), but it >doesn't bother to look to see that Word can be used. Doing something >behind the user's back? If he double-clicked on the file, he most >likely wanted to open it, and when the file brings up an error dialog >rather that being opened, the user thinks there's something funky >happening -- that's not the *intuitive* response. At the very least, >have it bring up an SFGetFile dialog: "An application for this >document could not be found. Choose another application to open it >with." ... and, optionally, remember this selection for later. > >As for the hooks: Why make it so that only hackers can tinker with the >resources to change the default applications? Remember when you used >to have to fiddle with the LAYO resource to make your desktop >prettier, and see how Apple now made that into a cdev? etc etc etc >etc... As a programmer and fairly sohpsticated Mac User, these are minor annoyances that I've learned to put up with. But what about the naive' beginning Mac user? There's no excuse for forcing a beginner to edit resources or to pull down the "Open" menu everytime they want to edit a file, because the application doesn't respond to "Open" puppet strings. The "completely intuitive interface for the rest of us" comes off as a pile of rubish when this is true. A lot of it isn't Apple's fault. Many applications are not written according to the interface guidelines and thus don't take advantage of the totally intuitive facilities. On the other hand, Apple certainly didn't make the Mac particularly easy for the application developers to use these facilities. There's grief to pay on both sides, but one thing I do know and that is that as a user I shouldn't have to fiddle with resources or worry about bundle bits or documents not having the correct type/creators or remembering to pull down "Open" instead of just double-clicking on a document to open it. No excuse whatsoever. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= ORGANIZATION: Advanced Decision Systems GEOGRAPHIC: Arlington, VA UUCP: kzin!speaker@mimsy.umd.edu INTERNET: jtn@potomac.ads.com