AppleScript_ The Definitive Guide - Matt Neuburg [275]
An interesting thing about Frontier is that, because a lot of its innards are implemented in UserTalk and are simply part of the database, we can look under the hood a little further. For instance, here's the script located at bbedit.make:
on make (new, at = nil, withProperties = nil)
return (appleEvent (BBEdit.id, 'core', 'crel', 'kocl', string4 (new), \
'insh', at, 'prdt', withProperties))}
Thus we see that it would have been possible to form and send the raw Apple event ourselves, as that's exactly what UserTalk is doing here. The built-in UserTalk verb appleEvent( ) constructs and sends an Apple event; its parameters tell it what event to construct. BBEdit.id is the four-letter code for BBEdit, stored in the id entry of the bbedit table. You know what core and crel are (the two four-letter codes of the Apple event we are to send), and kocl is the name of the parameter. The next item, called new, is the value for the kocl parameter, the class we are to make a new one of, which was passed in as the first parameter in the call to make( ); in this case it is the value of objectmodel.document (namely docu). The remaining parameters are optional; they are not supplied in this call, so they are not used in the construction of the Apple event.
For more information about Frontier, see my book Frontier: The Definitive Guide, from O'Reilly & Associates; it's out of print, but you can read it online at http://pages.sbcglobal.net/mattneub/frontierDef/ch00.html. The information in the book is somewhat outdated, but not all that much; Frontier has grown by accretion, not by internal alteration, and the implementation of Apple events is certainly unchanged. In fact, this is something of a problem. Frontier runs on Mac OS X, but has not been revised from its Classic origins to take account of many changed aspects of the file system, and there have even been a few changes in the system-level implementation of Apple events. Thus Frontier has become a bit rusty and unreliable as a way of expressing Apple events, which is a pity, especially because this is what it was originally created to do; indeed, Frontier and UserTalk were constructing and sending Apple events before AppleScript existed, and UserTalk's expression of Apple events remains one of Frontier's most elegant and powerful features. The other great disappointment is that UserTalk on Mac OS X is not an OSA language (as it was under previous systems), so it can be used only from within Frontier.
Perl
Perl has a surprisingly long history on the Macintosh; years before it was present as part of Unix in Mac OS X, it had been ported to the Classic Mac OS by Matthias Neeracher (see http://www.ptf.com/macperl). Modules to form and send Apple events were naturally part of this port (see http://www.ptf.com/macperl/depts/articles/IPCwMP.html). Support for these modules has continued, under the guidance of Chris Nandor, and they are available to Mac OS X users.
Once again, you have a choice: you can form the raw Apple events yourself, using Mac::AppleEvents, or you can use AppleScript terminology through Mac::Glue. The operation of Mac::Glue is similar to Frontier with its glue tables (and is probably deliberately modelled after it); a glue table for a given application must be formed and stored on disk before you can target that application using AppleScript English-like terminology. In order to get started, you will need Mac::Carbon (which includes Mac::AppleEvents) as well as Mac::Glue; on Tiger these are installed by default, but it can't hurt to check for more recent versions.
To make glue, run the gluemac Unix tool. For example:
% sudo /usr/bin/gluemac /Volumes/gromit/Users/matt2/extra/BBEdit\ 8/BBEdit.app
Making glue for '/Volumes/gromit/Users/matt2/extra/BBEdit 8/BBEdit.app'
What is the glue name?