AppleScript_ The Definitive Guide - Matt Neuburg [215]
When you use GUI scripting, you are essentially driving a a macro program that functions as an intermediary between AppleScript and the target application. Such a program has the power to "see" an application's interface and to act as a kind of ghost user, pressing buttons, typing keys, and choosing menu items. Anything a user can do in an application can presumably be performed through some definable sequence of mouse and keyboard gestures; therefore it might be possible to emulate that sequence of gestures with a macro program. The result might not be as fast, elegant, or flexible as true scripting by means of Apple events, but might get the job done. The macro program used here will be System Events (see Chapter 23).
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.