develop, The Apple Technical Journal, E D I T O R I A L S T A F F a quarterly publication of Apple Computer’s Editor-in-Cheek Caroline Rose Developer Press group, is published in March, Technical Buckstopper Dave Johnson June, September, and December. Our Boss Greg Joswiak This issue’s CD. The develop Bookmark CD (or His Boss Dennis Matthews the Developer CD Series disc, Reference Library Review Board Pete (“Luke”) Alexander, edition) for March 1994 or later contains this Jim Reekes, Bryan K. (“Beaker”) Ressler, issue and all back issues of develop along with the Larry Rosenstein, Andy Shebanow, Gregg code that the articles describe. The develop issues Williams, Dean Yu and code are also available on AppleLink and via Managing Editor Cynthia Jasper anonymous ftp on ftp.apple.com. Note that some Contributing Editors Lorraine Anderson, software and documentation referred to as being Toni Haskell, Judy Helfand, Elaine Meyer, on this issue’s CD may be located on the Tool Rebecca Pepper Chest edition rather than the Reference Library Indexer Marc Savage edition of the Developer CD Series disc. Macintosh Technical Notes. Where references to Macintosh Technical Notes in develop are A R T & P R O D U C T I O N followed by something like “(Memory 13),” this Production/Art Director Diane Wilcox indicates the category and number of the Note Technical Illustration Shawn Morningstar, on this issue’s CD. John Ryan E-mail addresses. Most e-mail addresses Formatting Forbes Mill Press mentioned in develop are AppleLink addresses; Film Services Aptos Post, Inc. to convert an AppleLink address to an Internet Prepress Production PrePress Assembly address, append “@applelink.apple.com” to it. Printing Wolfer Printing Company, Inc. For example, DEVELOP on AppleLink converts to [email protected] on the Internet. Photography Sharon Beals To convert a NewtonMail address to an Internet Cover Illustration Mark Jenkins of Rucker address, append “@online.apple.com” to it. Huggins Design Online Production Cassi Carpenter E D I T O R I A L User interface excesses. 2 L E T T E R S Floating windows corrections. 4 A R T I C L E S Using Proto Templates on the Newton by Harry R. Chesley For Newton developers, a sample game that uses proto templates to good effect; for everyone else, a flavor of what Newton development is like. 5 Standalone Code on PowerPC by Tim Nichols Standalone code is better and easier than ever before in the PowerPC environment. 36 Debugging on PowerPC by Dave Falkenburg and Brian Topping It’s a whole new world in there, but your hard-won debugging skills still work. 51 Concurrent Programming With the Thread Manager by Eric Anderson and Brad Post With both cooperative and preemptive threads, the possibilities provided by the new Thread Manager are nearly endless. 73 The Zen of Window Zooming by Dean Yu Everybody does it, but many still don’t do it right. Dean has some code to help you out. 101 C O L U M N S Print Hints: Tracking QuickDraw GX Messages by Pete (“Luke”) Alexander MessageWatcher lets you spy on QuickDraw GX printing. 32 The Veteran Neophyte: Why We Do It by Dave Johnson Why do people like to program computers? The results of an ad hoc survey. 48 Somewhere in QuickTime: Cross-Platform Compatibility and Multiple-Movie Files by John Wang The title says it all. 70 View From the Ledge by Tao Jones Amazing advice about awful allies. 99 Ten Tips for Game Developers by Brigham Stevens Things you should know if you want to write games for the Macintosh — or even if you don’t. 114 KON & BAL’s Puzzle Page: When Maps Go Bad by Konstantin Othmer and Bruce Leak More Macintosh orienteering with KON and BAL. 130 History of the Dogcow: Part 1 by Mark (“The Red”) Harlan Here it is for the first time — the real story, from someone who was there. 135 Q & A Macintosh Q & A Apple’s Developer Support Center answers your questions about product development, postage stamp glue, and more. 119 I N D E X 137 1 © 1994 Apple Computer, Inc. All rights reserved. Apple, the Apple logo, APDA, AppleLink, AppleShare, AppleTalk, ImageWriter, LaserWriter, MacApp, Macintosh, Macintosh Quadra, MPW, MultiFinder, PowerBook, Reanimator, and SADE are trademarks of Apple Computer, Inc., registered in the U.S. and other countries. AOCE, develop, the dogcow logo, Finder, Moof, Newton, QuickDraw, QuickTime, Sound Manager, SourceBug, System 7, and TrueType are trademarks of Apple Computer, Inc. PostScript is a trademark of Adobe Systems Incorporated, which may be registered in certain jurisdictions. NuBus is a trademark of Texas Instruments. All other trademarks are the property of their respective owners. CONTENTS March 1994 Dear Readers, We’re excited to bring you, in this issue, develop’s first Newton article. Even if you’re not set up for Newton development, you may find this article of interest. But it’s the article on zooming windows that inspired this editorial. The subject is user interface annoyances: those cases where the application doesn’t quite do what the user expects it to — as when a window zooms to an odd location — and the user has to adjust for it. So what’s the big deal? Well, it all adds up. Over time, the harm to the user from compensating for these problems can be physical as well as mental. You’ll end up with a customer who is suffering in more ways than one. As Joan Stigliani puts it in her forthcoming book, High-Tech Health: The Computer User’s Survival Guide: “Software can make you work hard and contribute to overuse if CAROLINE ROSE it requires a lot of mouse use — clicking and dragging, scrolling, moving the cursor back and forth across the screen — or a lot of complex key sequences or excessive keying. Software that is difficult or frustrating to use can increase stress and tension.” This especially struck a chord with me, since I suffer from tendinitis caused by excessive keying and mousing. So I’m going to take advantage of this opportunity to vent my frustration (isn’t that what editorials are for?). Mainly, I hope to have at least some small influence on how you design the interface for your applications in the future. Why do so many applications lack common sense? Why, for example, shouldn’t Print or Save work on my frontmost document even if the active window happens to be a dialog box? Why can’t I just type Command-F followed by text to be found rather than first have to select the text that the application (for some odd reason) didn’t choose to highlight in the Find dialog? Why, even on my two-page monitor, do I have to resize a teeny window for every piece of e-mail I receive, or read a mere eight lines at a time, scrolling repeatedly (excessively) to get to the end? Why, when I cut a double-clicked word and then paste it, do so few applications add spaces intelligently? The list of user interface superfluities goes on and on; these are only the problems I encounter most frequently each day. Please, give my hands (and my mind) a break! If I may make a few suggestions: •Don’t blindly follow what other applications have done: maybe they didn’t think it through well enough. There’s a place for 2 CAROLINE ROSE (AppleLink CROSE) started Publications group, but returned to the Apple fold writing and programming at a company called to edit develop. Caroline owes her love of the Tymshare, where she thought at first that the printed word to her father, who worked for the terminal was the computer. (She was stunned to New York Daily News for over 50 years. There learn it occupied a huge room in another was no greater thrill as a child than to go to the building.) By the time computers were the size of office with him and see the copy desks, terminals, Caroline was on her way to Apple to darkrooms, printing presses — and, of course, the write Inside Macintosh. She digressed to spend editors. She’d like to take this opportunity to say five years at NeXT, where she managed the thanks, Dad, and Happy 85th Birthday!• d e v e l o p Issue 17 guidelines and precedents, but don’t totally disregard common sense. •Use the application yourself for real tasks until you’re blue in the face. Be honest; what bugs you about it? Your users will be even less tolerant. •Do extensive user testing before first ship, of course — but even after you ship, solicit feedback and incorporate it into the next release. Be sure to get feedback from experienced users, not just first-timers. •Beware of creeping featurism: fix problems your testers or customers have with current features before adding new ones. These suggestions are based on my own experience as the user manual writer and ad hoc product manager for the first version of the WriteNow application. John Anderson, one of the authors of WriteNow, says he thinks interface problems stem from software being too hard to write (something his next product will address) and from the related problem of software teams being too large. With many specialized programmers on a project, no one person focuses on the overall picture well enough to make the requisite intelligent decisions about the interface. Given a large team, a good product manager can make all the difference in the world. Look for someone both knowledgeable about the market and able to grasp the technical issues.