I’m dipping a toe into programming my Mac… and it looks as if one of the best entry-level ways to do it is to use the scripting tools provided with the OS. They are installed under the Applescript folder which is in the Applications folder.

The script editor is a simple text editor which checks the syntax and runs the script.

After I fiddled with this for awhile, I actually went out and bought a book (!), AppleScript 1-2-3 A self-paced guide to learning AppleScript by Sal Soghoian an Bill Cheeseman. Amazon link here. It is useful and interesting to read reviews of the book, and other Applescript books, because you can gain a certain amount of insight about the AppleScript language itself. Not all of it is rosy commentary. For example, here is an excerpt from another review of an O’Reilly Applescript book…the book actually sounds quite good, however, with a publication date of 2006 it is a couple revisions back:

Apple has long pushed AppleScript as an easy-to-learn, English-like way of automating repetitive tasks on a Mac. Alas, I and many, many others have discovered from painful experience that AppleScript is hugely difficult to approach — its learning curve never seems to flatten out. Even after writing thousands of lines of code in several programs that (eventually) worked, I still feel I’m groping in the dark every time I try something new. I’ve read other books on AppleScript, looking for one that would open the magic door and reveal the simple, friendly AppleScript that’s supposed to exist.
Matt Neuburg has given us the first AppleScript book that tells the deep truth: AppleScript is a quirky, inconsistent programming language that is not only hard to learn, but hard to learn for fundamental, structural reasons. Neuburg exposes the unavoidable difficulties that are built into AppleScript’s design, and then shows us practical techniques for accomodating to them and using them.

Ok. Nevertheless, I’ve plowed on roughly halfway through the book. One of the other features of the scripting tool is the “dictionary”… this is essentially an object browser which allows you to look at all of the objects, events and commands of an application. If the developer wants to create an API for the application, they can expose objects, events and commands of the app. Here is an example of the dictionary chooser…I’m going to take a look at the Mac Mail application.

When I select Mail, I get the object browser. Commands that are unique to the Mail application appear when you select the Mail “suite” of commands. Here you can clearly see that if you want to check for mail, you can use the command as shown in the window. This suggests the following script:

This simple script will launch the mail program if it isn’t already active, and check for new mail.

More AppleScript tools

One tool suggested in the AppleScript 1-2-3 book is an enhanced Applescript editor called Script Debugger 4.5. This includes a debugger, and a greatly enhanced dictionary explorer. Very nicely done. It sells for $199. (There is a time-limited demo available, as well as number of free tools on their website.) You can install it on both a laptop and a desktop, as long as only one license is in use at one time. This really seems to take the sting out Applescripting. I admit I haven’t gotten very far in my travels yet… I’ve got a maximum script length of about 40 lines so far. Still I’m not entirely sure what all the book reviewers were making such a fuss about.

Other than simple dialog boxes for a single variable, you can’t create much of an interface in AppleScript. For more complex interfaces, with the usual Apple buttons, windows, and menus, you can use the AppleScript Studio, which grafts AppleScript capability on to the standard “Cocoa” Apple interface using the Interface Builder and XCode tools. Thats a whole other can of worms.