keith@Apple.COM (Keith Rollin) (05/19/89)
Most of you by now have probably heard of "Developer Helper:Phil & Dave's
Excellent CD". This is a CD released by Apple Developer Services to the
developers who showed up to the WorldWide Developers Conference last week,
and mailed to all the rest who weren't. It contains many tools, programs, and
files that are invaluable to developing any program.
Response to the CD has been fantastic! Way more than we expected! Demand for
the initial pre-release exceeded our stock (12,000) and 7500 more have to
be printed.
All of this has caused speculation here (at Apple) and on the nets as to what
should be done in the future about this. Many people would like to see more
things come from Apple on CD, and also have them distributed to wider
audiences.
I'd like to avoid most of the discussion on *WHAT* should be distributed, and
to *WHOM* it should be distritbuted; I don't think that there will be many
problems coming up with favorable decisions there. However, what I would like
to start a discussion about is how people would like to see the documentation
handled. Our documentation department writes everything in a word processor,
not in HyperCard, so converting to that medium (or any other for that matter)
would be difficult and time consuming.
So what would people like to see? MS-Word files? Text stashed into HyperCard?
Text stashed into HyperCard with Hypertext links? Perferences on some fancy
search and retrieval engines? "Read me" files in MPW format?
Ideally, whatever is done should be a solution that can be implemented
easily. This is because the gating factor of any CD distribution would be the
time it takes to put the documentation in an easily accessed form.
------------------------------------------------------------------------------
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, Contusionsoster@dewey.soe.berkeley.edu (David Phillip Oster) (05/19/89)
Apple should finally endorse some file format for fonted text + pictures. They should also endorse some clipboard format for the same data. I don't much care which format apple picks: (.) Microsoft's Rich Text Format (.) TEXT + STYL (which is what New Text Edit uses, as a clipboard format) (.) MacWrite version 2.2 Are all formats that spring to mind. Each has their limitations. Postscript, or any other format so general that you can write an inifinite loop "macro" is not a good idea, since programs will need to simply parse this format into their native format. But, please endorse _some_ single, well documented format. Issue a few public domain tools for reading or converting that format. The Macintosh is less than it could be as a result of this babel.
tim@hoptoad.uucp (Tim Maroney) (05/20/89)
Thanks for asking for ideas, Keith. Im sure the first one that comes to
my mind is the same as many others': Include the basic MPW. I understand
that the third-party compiler developers will scream bloody murder if you
include the C or Pascal compiler, so continue to make those separate
products.
Why include MPW, other than the fact that I'd rather not pay for it?
(1) There is a long tradition of including command language
interpreters with operating systems. No one else, to my knowledge, has
ever charged for them as a separate product. (Except as replacements
for the "free" CLI shipped with the OS.)
(2) CD-ROM is the natural medium for shipping a huge product like MPW.
Floppy disks don't make it at this size.
(3) If we can be reasonably sure every developer has MPW, then we can
expect a boom in developer utilities, given a standard environment for
them to execute in. I would expect a proliferation of both freeware
and payware devloper products compatible with MPW.
(4) It will increase pressure on third-party developers to come up with
versions of their systems that are compatible with MPW Shell, which
will be a boon to those devlopers who want to take advantage of various
wonderful MPW Power Tools. (I'd be *very* interested in an
MPW-compatible Lightspeed C, for instance.)
(5) No third party developer has a product similar to MPW (as long as
we exclude the compilers from "MPW proper"), so you aren't stepping on
anyone's toes.
(6) Apple makes its money from selling hardware, and the money from MPW
at present is infinitesimal relative to money from computer sales.
Apple can easily absorb this loss. The only thing it gains from
charging hundreds for low-distribution products like this is many
ruffled feelings and widespread software piracy.
--
Tim Maroney, Consultant, Eclectic Software, sun!hoptoad!tim
"Our newest idol, the Superman, celebrating the death of godhead, may be
younger than the hills; but he is as old as the shepherds."
- Shaw, "On Diabolonian Ethics"siegel@endor.harvard.edu (Rich Siegel) (05/20/89)
In article <7370@hoptoad.uucp> tim@hoptoad.UUCP (Tim Maroney) writes: >(4) It will increase pressure on third-party developers to come up with >versions of their systems that are compatible with MPW Shell, which >will be a boon to those devlopers who want to take advantage of various >wonderful MPW Power Tools. (I'd be *very* interested in an >MPW-compatible Lightspeed C, for instance.) The architecture of MPW is incompatible with the design tenets of LightspeedC (or Lightspeed Pascal, for that matter). For example, there is no way that the instant-link/instant run cycle can happen, due to the slowness of the MPW linker. (Not to spit on the quality of the linker - it's a good one, and it's got some features I could use.) In addition, the integration of tools to the shell is nowhere near as tight as it needs to be to maintain the project management and auto- make facilties, and the editor can't support features like option double- click to locate a symbol, or the pop-up menus that provide instant access to #include files. These are just examples; I'm not quoting official policy or anything like that. >(5) No third party developer has a product similar to MPW (as long as >we exclude the compilers from "MPW proper"), so you aren't stepping on >anyone's toes. Incorrect. Have you forgotten the Aztec C product from Manx? It's a command-line interface, with tool and editor support. Very much like MPW, but not as slick. (Commando's pretty nifty stuff!) --Rich ~~~~~~~~~~~~~~~ Rich Siegel Staff Software Developer Symantec Corporation, Language Products Group Internet: siegel@endor.harvard.edu UUCP: ..harvard!endor!siegel "She told me to make myself comfortable, so I pulled down my pants and sat in the pudding." -Emo Phillips ~~~~~~~~~~~~~~~
tim@hoptoad.uucp (Tim Maroney) (05/21/89)
In article <1881@husc6.harvard.edu> siegel@endor.UUCP (Rich Siegel) writes: > The architecture of MPW is incompatible with the design tenets >of LightspeedC (or Lightspeed Pascal, for that matter). For example, >there is no way that the instant-link/instant run cycle can happen, >due to the slowness of the MPW linker. Who said anything about using the MPW Linker? Obviously you're not going to undercut the advantages of your product. However, there is no intrinsic reason that LSC couldn't use the MPW Shell with its own linking capabilities. Incidentally, we're using the word "instant" in, shall we say, a creative manner, eh? >In addition, the integration of tools to the shell is nowhere near as >tight as it needs to be to maintain the project management and auto- >make facilties, and the editor can't support features like option double- >click to locate a symbol, or the pop-up menus that provide instant >access to #include files. True enough, but a few extensions to the editor should be easy enough to make. It's already extensible; adding more extensibility to support more powerful third-party products seems like something Apple ought to want to do. As for the pop-ups for include files, what are they? I was just commiserating with several other five-year Mac programmers the other day about how hard it can be to get at include files stored in the THINK C folder. None of us knew of a shortcut. One of my complaints about the LSC interface, good as it is overall, is that there are too many buried features. Stuff is supposed to be advertised in the menus and dialogs. >Have you forgotten the Aztec C product from Manx? >It's a command-line interface, with tool and editor support. Very much >like MPW, but not as slick. (Commando's pretty nifty stuff!) Yes, and I think most other people have forgotten it as well. MPW and Lightspeed are the two serious C compilers in the current market. I haven't used Aztec, but I doubt its tool set is anywhere near as rich as MPW's. In any case, it is a single-use system, not a general purpose one like MPW, and its main functionality (a C compiler) would not be infringed on by free distribution of the basic MPW Shell and tools. It would only be in competition if Apple were to distribute a free C compiler, which I recommend against (and which I'm sure they wouldn't do regardless of my advice!) Finally, Aztec really ought to just bring itself into line with MPW if it's so similar. I doubt porting its stdio-based (right?) tools would be more than the work of a week. -- Tim Maroney, Consultant, Eclectic Software, sun!hoptoad!tim "I have recently been examining all the known superstitions of the world, and do not find in our particular superstition (Christianity) one redeeming feature. They are all alike founded on fables and mythology." -- Thomas Jefferson
siegel@endor.harvard.edu (Rich Siegel) (05/21/89)
In article <7385@hoptoad.uucp> tim@hoptoad.UUCP (Tim Maroney) writes: > >Incidentally, we're using the word "instant" in, shall we say, a >creative manner, eh? Not really. When I run a program from the environment via the "Run" (or "Go", in Pascal), the link step takes less than a second, in most cases. Is that not instant? Also, "instant Run" describes the ability to turn around and run a program without having to smart-link and build an executable file, then launch it. (Launch time is the same for "instant" and "normal" running, but turnaround is vastly improved by not having to build. I try not to lie or be "creative" about our products' abilities. Do you accuse me of doing so? If you do, then say it. >complaints about the LSC interface, good as it is overall, is that >there are too many buried features. Stuff is supposed to be advertised >in the menus and dialogs. Oh, like the fact that you can type an ellipsis brings up Commando? Is *that* advertised in menus and dialogs? The ability to pop up a list of #include files is documented. I quote: "Hold down the Option or Command key as you click in the title bar of a source file's edit window to get a pop up menu of all the files included in the source file.... Holding down the Option or Command key as you click in the title bar of the project window brings up a pop up menu containing the names of all the #include files used in the project." - THINK C 3.0 User's Guide; Chapter 8 ("The Editor"), page 91. Being able to pop up includes in this fashion is a pretty good way to go, because it's easy to get at (you only have to go to the title bar), it doesn't require an extra menu in the menu bar, and it's a lot quicker and easier than having to bring up a dialog box. MPW, THINK C, and THINK Pascal all have their buried features, but they are also documented features. Your status as a power user and experienced developer doesn't relieve you of the need to read the manuals once in a while. Not everything is obvious. --Rich ~~~~~~~~~~~~~~~ Rich Siegel Staff Software Developer Symantec Corporation, Language Products Group Internet: siegel@endor.harvard.edu UUCP: ..harvard!endor!siegel "She told me to make myself comfortable, so I pulled down my pants and sat in the pudding." -Emo Phillips ~~~~~~~~~~~~~~~
dierks@ndmath.UUCP (Tim Dierks) (05/22/89)
From article <1886@husc6.harvard.edu>, by siegel@endor.harvard.edu (Rich Siegel): > The ability to pop up a list of #include files is documented. I > quote: I'd like to see including a precompiled file add its source and any files it includes to this menu. That way I could include the precompiled MacHeaders, but still be able to bring up the header files it was compiled from, which I use as a reference farily often. (I find it easier to check a spelling or look up a structure element in the files than wrestle with Inside Macintosh.) Then they could also be included in the Multi-File search dialog box. (Both of these are especially handy if you're using a custom precompiled header.) Tim Dierks dierks@darwin.cc.nd.edu -- Tim Dierks dierks@darwin.cc.nd.edu - Apple Student Rep, University of Notre Dame I do not like green eggs and ham, I do not like them, Sam I Am.
dave@suna.CMI.COM (David Halonen) (05/22/89)
I've had access to the Tech Notes in three formats: paper, MacWrite, and the HyperCard version. I seldom look at the paper ones, as it is hard to quickly find all of what you need. The MacWrite TechNotes are on a fileserver. I peruse(sp?) these notes with Gopher(tm) when looking for specific concerns and this works fairly well. I would advocate a HyperCard implimentation for "static" text. Its already organized (alphabetically, by subject, by number, etc...), which saves one time when trying to quickly locate relevant information. IMHO, David Halonen, Center for Machine Intelligence, Electronic Data Systems Ann Arbor, MI (313) 995-0900 AppleLink: N0548 Internet: dave@suna.cmi.com -- David Halonen, Center for Machine Intelligence, Electronic Data Systems Ann Arbor, MI (313) 995-0900 AppleLink: N0548 Internet: dave@suna.cmi.com
milo@ndmath.UUCP (Greg Corson) (05/23/89)
After taking some time to look through the developer helper CD, I have
only a few comments.
1. It needs a better index! Possiblly a keyword searchable Hypercard stack
or somthing similar. Perhaps something like "find-file" but with a
pre-generated index so it wouldn't have to search the whole CD.
2. There should be a little more info on the items themselves...just a
comment in the GET INFO box would be nice.
3. Many items did not include any real documentation...this makes them almost
worthless. For example, RAMdump and ReAnimator had NO documentation at
all, even to tell you what they were for. There was also no doc for
ADSP (Apple data stream protocol)...it would be nice to at least have a
quicky installation doc or better-yet a how-to-use document along the
lines of the sound manager chapter found elsewhere on the disk.
The HyperAppleTalk stuff had documentation...but a lot of the rest of
the stuff did not even have an installation documents.
Overall, the CD is a great idea, but it needs better indexing and needs to
include more documents.
Has anyone at Apple considered supporting the CDA (compound document
archetecture) format for text/graphics files? This is the format supported
by DEC and other manufacturers.
As far as documentation on a disk...a documentation browser like DEC's
"bookreader" would be a good way to set it up. It gives you a chapter
based index, click on a chapter to get the text. There are also hypertext
links to pictures and other sections of the documentation. ie: click
"see figure one" in the text and you get a window with figure 1. If it
says See section 3.21 you click on that text and section 3.21 appears.
I'm sure you could do this with hypercard...but it might be difficult to
preserve all the fonts, pictures and styles. I know the hypercard version
of technotes is all plain text. The "bookreader" approach leaves in ALL
the original features of the document, typestyles, bold-lightface,
lines, tables, drawings...etc. If you are going to put Inside Macintosh on
a CD, it would be a lot more useful if all that information were preserved.
Greg Corson
19141 Summers Drive
South Bend, IN 46637
(219) 277-5306
{pur-ee,rutgers,uunet}!iuvax!ndmath!miloech@pegasus.ATT.COM (Edward C Horvath) (05/24/89)
In article <7370@hoptoad.uucp> tim@hoptoad.UUCP (Tim Maroney) writes: >(5) No third party developer has a product similar to MPW (as long as >we exclude the compilers from "MPW proper"), so you aren't stepping on >anyone's toes. In article <1881@husc6.harvard.edu> siegel@endor.harvard.edu (Rich Siegel): > Incorrect. Have you forgotten the Aztec C product from Manx? > It's a command-line interface, with tool and editor support. Very much > like MPW, but not as slick. (Commando's pretty nifty stuff!) I don't speak for Manx, but the Aztec C Shell was developed at least two years before the MPW Shell; we modified the tools in the Aztec package to run under MPW precisely so we could leverage off Apple's (considerable) effort. Manx continues to ship the Aztec shell with the package for those who don't want to spend the extra hundreds for the MPW shell. But I frankly doubt that anyone -- including Jim Goodnow, who wrote the shell initially -- would weep many tears if they didn't have to maintain it any longer. Of course, it's still faster than the MPW shell, but I traded that for the convenience a long time ago. =Ned Horvath= Disclaimer: I don't work for Manx. I was responsible for the MPW port.
wilkins@jarthur.Claremont.EDU (Mark Wilkins) (05/26/89)
In article <31042@apple.Apple.COM> keith@Apple.COM (Keith Rollin) writes: >So what would people like to see? MS-Word files? Text stashed into HyperCard? >Text stashed into HyperCard with Hypertext links? Perferences on some fancy >search and retrieval engines? "Read me" files in MPW format? How about implementing one of the WP-based options, like "Read me" MPW files or something, with a simple HyperCard index stack which would start off knowing something about the CD's layout and allow the user to pick an item on which (s)he wants documentation. Then, the stack would read the text into a scrollable field. That way, someone could browse and double-click on a "Read me" to get information OR use a HyperCard stack to find needed information. Of course, someone would have to create an index and a whole bunch of applicable keywords for all the stuff on the disk but it would be versatile. -- Mark Wilkins
jimo@phred.UUCP (Jim Osborn) (05/31/89)
keith@Apple.COM (Keith Rollin) writes: >..."Developer Helper:Phil & Dave's Excellent CD"... >It contains many tools, programs, and files... >I would like to start a discussion about how people would like >to see the documentation handled: Since we're talking about PROGRAMMING aids here, wouldn't it be nice if we could look at (and print) them with the text editor we use while we're programming? That ain't MS Word, or MacWrite, or any of those fancy things. I use either the Think C editor or emacs, and find it a real pain whenever documentation forces me elsewhere. jimo -- pilchuck!jimo@phred Jim Osborn, Physio Control Corp 11811 Willows Rd, Redmond, WA, 98073 206-867-4704 direct to my desk
mjohnson@Apple.COM (Mark B. Johnson) (06/01/89)
In article <2602@phred.UUCP> jimo@phred.UUCP (Jim Osborn) writes: >keith@Apple.COM (Keith Rollin) writes: >>..."Developer Helper:Phil & Dave's Excellent CD"... >>It contains many tools, programs, and files... >>I would like to start a discussion about how people would like >>to see the documentation handled: > >Since we're talking about PROGRAMMING aids here, wouldn't it be nice >if we could look at (and print) them with the text editor we use >while we're programming? That ain't MS Word, or MacWrite, or any >of those fancy things. I use either the Think C editor or emacs, >and find it a real pain whenever documentation forces me elsewhere. We put as much as we could (time permitting) into TEXT format. That is where you get things like the Technical Notes Stack and the Sample Code files (and Sample Code Notes). Since most of the information does not originate in plain ASCII, we have to convert it then maintain separate versions. We're doing what we can, but you can only do so much with caffeine and 10 fingers. We'll keep working on it though. Mark B. Johnson AppleLink: mjohnson Developer Technical Support domain: mjohnson@Apple.com Apple Computer, Inc. UUCP: {amdahl,decwrl,sun,unisoft}!apple!mjohnson "You gave your life to become the person you are right now. Was it worth it?" - Richard Bach, _One_