Section B.3. UserTalk

B.3. UserTalk

UserTalk is the native scripting language of UserLand Frontier and its inexpensive "little brother," Radio UserLand. Frontier is now also once again available in a free version, which is open source.

UserTalk does not read an application's dictionary in real time, the way JavaScript OSA does. In UserTalk, all terminology (not only as relates to Apple events, but the entire language) is implemented through a hierarchical namespace table called "the database." Every name in the database corresponds to a value; a value can be a string, an integer, a raw four-character code, a script written in the UserTalk language, a subtable, or any of a dozen other types of value. The namespace is navigated through dot notation, starting at the top level, which is called root. Certain nodes in the database are short-circuited, though, so that an unqualified term is sought at these points directly. English-like AppleScript terminology is implemented through the database, like everything else; to drive an application, you need a table to translate from English-like terms to four-letter codes, scripts, and so forth. This is called the glue table for that application. Construction of a glue table must be performed separately before you can start targeting a given application. The process of constructing a glue table is largely automatic (Frontier includes a script that can read an application's dictionary and generate the corresponding table), but too involved to describe here. Let's just assume, therefore, that we have previously constructed a BBEdit glue table. Then the code to generate our model events is as follows:

 if !(bbedit.isRunning( ))     launch.application(bbedit.appinfo.path) with objectmodel, bbedit     make(document)     set(document[1].text,"Hello, world!")

The term bbedit refers to our glue table (located in the system.verbs.apps table, one of the short-circuited areas of the database). The term objectmodel refers to a table in system.macintosh (another short-circuited area) where certain common terms are defined. The with clause means: "Look for these terms starting in objectmodel, and if you don't find one, look for it in bbedit instead." As a result, make and set are found in bbedit, whereas document and text are found in objectmodel. As you can see, the code looks very much like the JavaScript OSA expression of the same events, pleasantly compact and legible. As with JavaScript OSA, dot notation and array notation are used to assemble an object reference.

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.