Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!wuarchive!hsdndev!husc6!unix!mxmora From: mxmora@unix.SRI.COM (Matt Mora) Newsgroups: comp.sys.mac.programmer Subject: Re: Gripes about System 7.0 Message-ID: <20359@unix.SRI.COM> Date: 24 Jan 91 18:24:49 GMT References: <20283@unix.SRI.COM> <11831@goofy.Apple.COM> Reply-To: mxmora@unix.UUCP (Matt Mora) Organization: SRI International, Menlo Park, CA Lines: 125 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 ___________________________________________________________