Section 24.1. Historical Perspective

24.1. Historical Perspective

Back in the pre-Mac OS X days, there were a number of very strong macro programs, such as QuicKeys , PreFab Player , and OneClick (see Appendix C for URLs). These depended upon a feature of the system architecture whereby third-party code fragments called system extensions (or INITs ) could be loaded into the system at startup in such a way as to modify the system's response to Toolbox calls. The code fragment would effectively interpose itself into the Toolbox call dispatch architecture, so that when the system was about to execute a certain piece of its functionality, this code fragment would be called instead; usually it would also call the system's original functionality, so as not to break the computer altogether, but along the way it would introduce functionality of its own. (On INITs, see Joe Zobkiw, A Fragment of Your Imagination [Addison-Wesley, 1995], Chapter 4.)

The trouble with this approach was that INITs were a threat to stability and reliability. They caused no end of headaches for users, who often found that different INITs conflicted with one another, and for application developers, who would learn that their application misbehaved in the presence of some INIT. The ability of users to customize their own systems meant that every user's system could be essentially different from every other's.

On Mac OS X, INITs are abolished. In fact, that's part of the point of Mac OS X: at bottom, every system should be a clean system, and all machines should reliably work the same way. But without INITs, there's no way for a third-party macro program to hook into the system's functionality at a level low enough for it to do the things that a macro program needs to do. This, in the early days of Mac OS X, made scripting the unscriptable next to impossible; and there was serious doubt as to whether there could ever be a macro program on Mac OS X.

Then, however, a solution emerged from Apple itself. As part of an effort to make Mac OS X accessible to people who may not be able to use a mouse and keyboard or see a computer screen, Apple created the Accessibility API , a set of Toolbox commands that can do just what a macro program would do"see" an application's interface and manipulate it like a ghost user wielding an invisible mouse and keyboard. Going even further, they made the Accessibility API itself scriptable via AppleScript, by way of System Events. When you do GUI scripting, you use AppleScript to send Apple events to System Events, which translates your commands into terms that the Accessibility API can understand.

Although GUI scripting definitely has its uses, some of them very serious (such as automating a suite for testing the interface of an application under development), and although it is valuable for working around holes in scriptability (as the examples in this chapter will illustrate), it is not a panacea. It doesn't work everywhere; a particular interface item, a window, or an entire application might not use the standard interface elements. In that case, the Accessibility API can do nothing for you. And in any case, for your purposes as an AppleScript programmer, real scriptability is always better. If you're reduced to using GUI scripting to accomplish some goal, and if the target application is still being actively developed, then consider writing to the developer and requesting that the desired aspect of the target application be made properly scriptable.