Volume Number: 18 (2002)
Issue Number: 01
Column Tag: AppleScript and Cocoa

AppleScript Studio: An Introduction

by Bill Cheeseman, Quechee, VT

Building Cocoa Applications for Mac OS X with AppleScript

AppleScript Studio has been one of the most eagerly awaited new products among AppleScripters since the announcement of Mac OS X. Ambitious script writers have been able to create applications with full-featured user interfaces since the beginning, in 1993, when Apple's first release of AppleScript included Frontmost, a third-party application interface development tool based on AppleScript. Because Frontmost's successor, FaceSpan, has been a separate commercial product for a long time, freeware and shareware solutions of lesser capability have also been popular, including Chris Hyde's powerful but unfinished Dialog Director scripting addition. But FaceSpan and the other existing solutions have not been ported to Mac OS X to date. AppleScript Studio has therefore excited hopes for a truly powerful application development tool that will allow scripters to create applications native to Mac OS X, complete with an Aqua-compliant user interface with menus, windows, dialogs, sheets, buttons, text fields, and a host of other user controls that are not normally a part of AppleScript. Its enhanced editing capabilities, support for text exceeding 32K, and debugging tools have also been anticipated by those grown tired of Script Editor's severe limitations.

AppleScript Studio has also attracted considerable attention in the Cocoa developer community. It is based on the Cocoa application frameworks, and it provides interesting new capabilities to Cocoa applications. These include enhanced AppleScript terminology for all Cocoa applications, the ability to write scripts to control a Cocoa application's user interface for quality assurance testing and product demonstrations, and other features.

Popularly known by its cute little acronym, ASS, AppleScript Studio was first released in final form on December 5, 2001 to a restricted audience of Premier and Select members of the Apple Developer Connection (ADC). Release to all members of ADC followed a few days later. Since online membership in ADC is free and open to all, this was effectively the initial public release of the product. It was first provided as a download of the December 2001 Developer Tools CD, one of the regular quarterly updates to Apple's suite of Mac OS X developer tools, that usually include new versions of Project Builder and Interface Builder and updated documentation for the Carbon and Cocoa development environments. The CD itself, which is being mailed to ADC members in January 2002, also includes AppleScript 1.8 for Mac OS X, an upgrade required for AppleScript debugging in Project Builder. The download from the ADC Web site is more than 200 megabytes. The Mac OS X 10.1.2 update, apparently imminent at this writing, will also include AppleScript Studio and all necessary supporting software.

It is hard to describe AppleScript Studio as a separate product, because much of it consists of enhancements to existing software that continues to fulfill other purposes. For example, the new AppleScript editor is simply an additional feature incorporated within the existing development tool Project Builder, as is the new AppleScript terminology, or dictionary, viewer. Similarly, the existing development tool Interface Builder is enhanced with a new AppleScript palette for the Palette window and a new AppleScript pane for the Info panel. A new framework, AppleScriptKit.framework, is installed in the Frameworks folder of the System Library. Other features of the product are separate files, including a 200-plus page PDF file containing the instruction manual, Inside Mac OS X: Building Applications With AppleScript Studio, the usual Release Notes, and a folder full of Example projects ready to be compiled and studied. The overall effect is of a finished and highly polished product, although there are a couple of rough edges (for example, one handler in the principal example project, Watson, is stubbed out because, as the Release Notes candidly acknowledge, the code as listed in the manual doesn't work).

Requirements for using AppleScript Studio are Mac OS X 10.1.2 or Mac OS X 10.1.1 with the December 2001 Developer Tools CD. Applications written with AppleScript Studio will run only on computers meeting these requirements; they will not run on Mac OS X 10.1 or older, nor on the classic Mac OS.

AppleScript Studio makes it possible to use Apple's powerful development tools, Project Builder and Interface Builder, to build full-featured applications written in the AppleScript scripting language. For the first time since Apple shipped Frontmost, the predecessor of FaceSpan, with AppleScript in 1993, it is possible to build a complete user interface for your AppleScript applications using an Apple-supplied tool.

To say that an AppleScript Studio application is written in AppleScript is not to tell the whole story, however. What is true is that an AppleScripter knowing nothing of Objective-C can create an application by writing pure AppleScript. Under the hood (or "behind the curtain," as the manual is fond of saying), an AppleScript Studio application is nevertheless a Cocoa application, pure and simple, with all the Objective-C code from the Cocoa frameworks which that implies. Furthermore, a knowledgeable developer can mix in Objective-C code along with AppleScript code. In fact, an AppleScript Studio application can be anywhere from almost all Objective-C code to almost all AppleScript code, as far as developer-written code is concerned.

AppleScript Studio is, therefore, a direct descendant of NextStep and OpenStep, Cocoa's predecessors, benefiting from all of the maturity and sophistication of that history. The user controls and other interface widgets available in AppleScript Studio, for example, come straight out of Apple's Cocoa Application Kit classes. The AppleScript support already built into Cocoa's AppKit, combined with the AppleScript Studio enhancements, give a developer very extensive control over an application's user interface via AppleScript. An AppleScript Studio application is in fact a Cocoa application, having all of the built-in features of any Cocoa AppKit-based application, such as opening multiple windows, drag and drop editing, and text fields that work as expected, with almost no coding required except to add custom application-specific features.

It is AppleScript Studio's foundation in Cocoa that makes it useful to Cocoa developers as well as to AppleScripters. It was noted above that AppleScript Studio provides enhanced scriptability to any Cocoa application that is built with AppleScript support turned on. This additional scriptability relates mostly to the user interface. While AppleScript has traditionally focused on the scripting of data, there has also been interest in scripting the interface — particularly in graphics applications, where the data is the interface, in a manner of speaking. Now, with AppleScript Studio's very thorough-going scriptability added to every user control and widget, Cocoa developers can use AppleScript for automated quality assurance testing and product demos. Of potentially greater value to Cocoa developers, however, is the ability to place AppleScript code anywhere in your application. You can write simple scripts as temporary placeholders for Objective-C methods not yet written, to help with prototyping, and you can write permanent AppleScript statements into your application to handle functionality that does not require the greater speed of Objective-C code. There is even a new AppleScript command to call an Objective-C method.

From an AppleScripter's point of view, it will likely be Interface Builder that elicits the loudest ooh's and aah's. While FaceSpan's graphical user editing tools have long allowed similar drag-and-drop placement of user controls on a canvas, Interface Builder is more sophisticated. The Aqua "guides" that appear magically in Interface Builder when a control is dragged near a window's edge or close to another control are magnificent tools to ensure easy compliance with the detailed size and placement requirements of the Aqua Human Interface Guidelines. Editing features of Project Builder will bring widespread sighs of relief, since it is not hobbled by the much-maligned 32K text limit of Apple's Script Editor, and it permits drag-and-drop editing and full search and replace in scripts, features with which users of Script Editor have gone without all these years. But the biggest benefit of Project Builder for scripters will be its full support of debugging, including break points, single-step execution, and the ability to display and set variable values on the fly.

Apple suggests that little, if any, prior experience with Apple's development tools and with the Cocoa frameworks is required. However, the documentation acknowledges that reading the Project Builder and Interface Builder tutorials and reading a Cocoa programming book such as "Learning Cocoa" will pay dividends, and the comments of first-time users of AppleScript Studio indicate clearly that some understanding of the Cocoa frameworks is more than just helpful, but essential, at least until more complete documentation written for AppleScripters becomes available. All of this may suggest to you that AppleScript Studio is not for the faint of heart. If you are a beginning AppleScripter, you will be well advised to stick with Apple's bare bones Script Editor or a third-party AppleScript editor and debugger, such as Script Debugger from Late Night Software. Even advanced scripters are likely to find a dedicated AppleScript editor like Script Debugger preferable for most AppleScript work, especially for compiled scripts (whether simple or complex) that don't require a fancy user interface.

The result of compiling an AppleScript Studio project is a native Mac OS X application compliant with the Aqua interface, a full Mac OS X citizen. AppleScript Studio is not only a suitable vehicle for rapid application development using the easy, English-like syntax of AppleScript, but also for finished, real world applications that are aimed, for example, at controlling multiple applications (workflow control in the publishing industry, say), manipulating data associated with user controls, and displaying information provided by other scriptable applications. Because of the limitations of AppleScript, it may not be suitable for applications that manipulate large amounts of data, that require intense interaction with the file system, or that require real time or other fast processing.

When you write an AppleScript Studio application, you typically start with a pre-made application template in Project Builder. Three are provided: one for applications that don't create documents, one for document-based applications, and one for droplets, applications that work with files dropped on them. As far as you can see at first glance, each template is very simple; in fact, the starting script in two of the templates is empty. Behind the scenes, however, the Cocoa AppKit framework has already supplied you with a working application, just waiting for you to add a user interface along with AppleScript scripts to control it and any data objects that your application will manipulate. In addition, the templates preconfigure all the Project Builder compiler and linker settings that would otherwise confuse any but the most expert user of these tools. The templates also include the appropriate Interface Builder "nib" files, ready for you to begin designing your application's graphical user interface and menu bar.

What the simplest AppleScript application template provides to you is an application object, a menu bar with some standard menus and menu items, an empty window, and a hidden Objective-C run method. When it is compiled and run, the application will automatically do three fundamental things: it will display whatever interface you design; it will receive an event (not an Apple event, but a system event) whenever a user clicks a user control or other object in the interface; and it will distribute the event to the script or other object that must handle it. Your role is simply to design any windows, user controls, additional menus and additional menu items that will form the unique user interface of your application, using Interface Builder; and, using Project Builder, to write the AppleScript handlers (called "event handlers") that will be triggered when the user controls are clicked, to write other handlers that will service these event handlers, and to create data and other objects that will be acted upon by these handlers.

The interface objects and connections that you create in Interface Builder are archived in so-called "nib" files. The AppleScript Studio documentation refers to these as "user interface resource files." Rumor has it that "nib" stands for "Next Interface Builder," reflecting the origins of AppleScript Studio and Cocoa in NextStep. The nib file becomes part of the application bundle when the application is compiled, and it is loaded into memory and its contents are dearchived when the application is run.

The compiler and linker turn all of the files composing the finished template into an executable program, which takes the form of a proper Mac OS X application bundle. Although it appears on the desktop as a single application file, Control-clicking on it to bring up the contextual menu's "Show Package Contents" menu item will reveal its components, which will look very similar to the files composing the original template.

AppleScript Studio comes with a new volume of Inside Mac OS X. As far as it goes, this is an excellent manual written in the best Apple tradition. The bulk of it is a long tutorial in which you build a fairly complex application named "Watson." Working through the tutorial is highly recommended, even if you are already familiar with Project Builder and Interface Builder. The techniques used to build an AppleScript Studio application are sufficiently different from those used to create a traditional Cocoa application that the exercise will prove valuable to everyone. In particular, even Cocoa old-timers will need to become familiar with the use of the new AppleScript pane in Interface Builder's Info panel and the AppleScript editor in Project Builder.

The manual is quite explicit about its limitations, and it is remarkably agnostic about its audience. If you are a veteran AppleScripter who knows nothing of Cocoa, Project Builder and Interface Builder, it tells you where to find the Cocoa and related documentation and advises you to read it. If you are a Cocoa programmer who knows nothing of AppleScript, it tells you where to find the AppleScript Language Guide and other AppleScript resources and advises you to read them. I happen to be conversant with both AppleScript and Cocoa, so I found the manual to be extremely easy going and very helpful.

AppleScript Studio lies at the intersection of Cocoa and AppleScript, and my first reaction was that the manual does a great job of exposing you to just enough of each to get you off to a good start. It seemed clear to me that the AppleScript Studio document can't be expected to explain all of Cocoa and all of AppleScript. It is essentially a tutorial. Much more exhaustive technical documentation for those two technologies already exists, and anyone hoping to make good use of AppleScript Studio will have to master some of it.

Exercising a little imagination, however, I began to see that people who know only one of these two platforms might get bogged down at first. In discussions with accomplished AppleScripters who are not familiar with Cocoa, in particular, I have been admonished—correctly, I think—that, while the AppleScript documentation available to Cocoa programmers is suitable, the Cocoa documentation available to AppleScripters is, at the same time, both too much and not enough. The existing Cocoa documentation provides too much irrelevant technical information for an AppleScripter, and it is couched in the language of Cocoa, Objective-C and Java, not AppleScript. Predating AppleScript Studio, it does not explain the different AppleScript Studio terminology, and it does not adequately tie the somewhat mysterious technologies of Cocoa to their AppleScript Studio counterparts.

Additional documentation of AppleScript Studio is therefore needed that goes beyond a tutorial and provides an exhaustive specification of the Cocoa user interface objects and their use, written for AppleScripters using AppleScript Studio's AppleScript terminology and conventions. At the same time, AppleScripters need an overview document that explains the basic operating principles of a Cocoa application, such as delegate methods and their relationship to AppleScript Studio's event handlers. The brief discussion of the "target-action" design pattern in the AppleScript Studio document, for example, makes clear that this is an area where an AppleScripter ignorant of Cocoa might have difficulty.

The manual is not without the occasional confusing passage that slipped through the beta review process. For example, in the instructions about connecting the text field in Watson's search window, the manual briefly describes the target-action design pattern used in Cocoa, saying that, "in Cocoa, the target is a method, but here it is a handler." This is true, but I would have found it helpful if the manual had explicitly pointed out as well that a Cocoa target method is connected using the Connections pane of Interface Builder's Info panel, while, as described, the AppleScript handler is selected in the AppleScript pane. In other words, the AppleScript pane is a specialized form of the Connections pane.

This same passage in the manual presents another potential problem for readers. In giving a brief description of the Cocoa target-action design pattern, it uses as an example the "action" event handler. A first-time reader might assume from the text that the name of this event handler, "action," is somehow unique to the text field control that is used in the example, but it is not. It is in fact implemented in AppleScript Studio's control class, from which text fields and other user controls inherit some of their terminology. A text field can be set to send its action message in either of two ways: when editing has ended by any means, for example, by clicking elsewhere in a window, by tabbing out of the text field, or by pressing Return or Enter, or, instead, only when the Return or Enter key is pressed in a text field that acts like a button. But, in Cocoa's target-action design pattern, all controls send a so-called "action message" when they are clicked or in response to some other user interaction. The documentation does not adequately explain this. Furthermore, "action" is a programmer's choice of words describing literally what is happening behind the scenes in Cocoa: an action message is sent. In some cases the handlers are given names, such as "clicked" or "double-clicked," that are more meaningful to a user or scripter. All of these are categorized as "action" handlers in AppleScript Studio, one of several subspecies of event handler. It would have been better, from the point of view of the typical scripter who is used to AppleScript's plain-English tradition, if a text field's "action" event handler had been named something more descriptive, such as "editing ended" (the corresponding Cocoa delegate method is "textDidEndEditing"). Even the generic action handler in the control class might more effectively have been named "action sent." Given the very short description of the target-action design pattern here, I suspect that every reader who doesn't know Cocoa emerged with glazed eyes. In general, I have found that a brief explanation of delegate methods in Cocoa is a very helpful eye-opener in getting AppleScripters to understand the point.

There is one warning in the manual about a step in application development that is required in order to prevent loss of your scripts. Ignore or overlook the warning at your peril. At the top of page 159 in the section about connecting the interface, an "important" note tells you "always" to save a script file you have edited in Project Builder before switching to Interface Builder to add more connections. To a reader attuned to the conventions of software manuals, this is a dead giveaway that there is a serious problem with AppleScript Studio. If you edit a script in Project Builder, fail to save it, then switch to Interface Builder to add a new event handler and edit its script, you may be presented with an alert in Project Builder. The alert tells you that a script has been modified in another application (apparently meaning Interface Builder) and hasn't been saved, and it asks whether you want to keep your Project Builder version or revert to the version on disk. This message is quite confusing, partly because you might think it is presented by Interface Builder. Which version of the script will be preserved if you click Revert; which, if you click Keep Project Builder Version? If you click Revert, your Project Builder edits will be irretrievably lost without further warning. Worse yet, the alert apparently is sometimes delayed or opens behind other Interface Builder windows (I can't tell, but I always end up with two alerts, not one). Fortunately, the Keep Project Builder Version button is the default. Unfortunately, selecting it does not actually save the script, as you might think, so a later Revert will wipe out all of the earlier Project Builder edits you thought you had "kept," if you haven't also explicitly saved them in Project Builder. This needs to be fixed, because the warning in the manual is not very prominent and is easily forgotten. There are already users who have lost dozens of event handlers and hours of work in this manner.

There are a few areas in which AppleScript Studio handles things differently than they are normally handled in AppleScript. These are scattered throughout the manual, so I will consolidate them here because they are already surprising AppleScripters.

The content of text fields in AppleScript Studio is Unicode text, but some AppleScript commands expect ordinary text. You may therefore have to coerce text obtained from a text field to a string before using it in an AppleScript command. For example, when sending a remote event to another machine using the statement tell application "Finder" of machine X, you may have to pass X as string.

The Display Dialog command from Standard Additions is overridden to allow you to display dialogs as Mac OS X sheets. It uses slightly different syntax..

Line endings in scripts created in Project Builder are, by default, UNIX line endings. These will appear as garbage characters if you copy and paste them into Script Editor. You can avoid this problem by changing a preference in Project Builder.

AppleScript Studio scripts will not compile in Script Editor if they reference any of the special commands or objects used in AppleScript Studio. You can avoid this problem by enclosing the offending statements in a Using Terms From block targeting any AppleScript Studio application.

Some other gotchas are not mentioned in the manual.

A stay-open droplet is created by deleting the Quit command from the script provided by the AppleScript Droplet template. Although the manual explains that the default AppleScript Droplet template quits automatically when it has completed its assignment, the manual does not explain that you should add a Quit command of your own in the run handler of an AppleScript Application or an AppleScript Document-based Application if you do not want an applet to stay open; these two templates, unlike the droplet template, are stay-open by default.

The AppleScript Run and Reopen handlers do not appear to do anything in AppleScript Studio. They do not appear in the AppleScript pane of Interface Builder's File's Owner Info panel under the Application category, where the activated and open event handlers appear, so you can't connect them to an event handler.

It is important to try to understand what uses AppleScript Studio will have in the AppleScript community and in the larger world of Mac OS X applications, and what space is left for existing tools. While it is "too early to tell," a few prognostications are in order.

Should Apple discontinue Script Editor? Should the developers of third-party AppleScript development tools such as Script Debugger, Scripter, Smile and FaceSpan give up and abandon the field? Will we all use AppleScript Studio exclusively hereafter for AppleScript development? The answer to each of these questions is clearly "No," it seems to me.

Script Debugger and Smile are already available in Carbonized versions for Mac OS X, as well as Mac OS 9, and rumors that FaceSpan is being ported to Mac OS X are widespread. An upcoming revision of Script Debugger will interoperate with AppleScript Studio. Script Debugger already handles the Unix line endings of AppleScript Studio script files, but the new version will also handle their lack of traditional type and creator codes and compile them successfully. Furthermore, Script Debugger's powerful and time-tested debugging tools will work with AppleScript Studio files, and Script Debugger's user interface will integrate access to AppleScript Studio's dictionary.

The easiest argument supporting the continuing value of Script Editor and the third-party AppleScript development tools is that they run in Mac OS 9 and create scripts and applications that run in Mac OS 9, while AppleScript Studio and the applications it creates require Mac OS X. As long as older Macintosh computers that cannot run Mac OS X are in use, there will be a clear place for AppleScript tools that run on and for the classic Mac OS. More importantly, as long as there are important scriptable applications that run only on Mac OS 9 or earlier, these third-party tools will have an important role. For example, many of the applications used in AppleScript's traditional bastion of strength, the publishing industry, remain available at this time only in versions for the classic Mac OS, and many very complex scripts to control them in automated workflows are written for Mac OS 9 and earlier. While it is true that Mac OS X scripts can control applications running in the Classic environment, until these publishing applications exist in Mac OS X-native versions there will be little or no economic pressure to convert the scripts that tie them together to Mac OS X.

Another, more fundamental reason for the continued viability of Script Editor and the third-party AppleScript tools is the ongoing need of many Macintosh users to customize their daily work. It has always been an important function of AppleScript to make it easy to automate the simple, everyday, repetitive actions that we all have to perform every day. The Web is rife with AppleScript collections written by individual users, providing access to simple (and not so simple) AppleScript solutions for such conveniences as automatic archiving of email messages to a database, automatically changing desktop pictures at random, expanding the capabilities of chat room software, performing file maintenance in the Finder, and so on. These scripts can easily be made part of an ordinary user's daily routine by installing them in the Apple menu, in an application launcher palette, or in a scripts menu. By and large, these scripts are short and of low to medium complexity. And they very often require only the most limited user interface, or none at all.

AppleScript Studio is not only overkill for these kinds of scripts, but it can't even create most of them. Most of these scripts are so-called "compiled scripts," not applications. As such, they execute very quickly in a utility that provides an execution context for them, such as a scripts menu, whereas an AppleScript application incurs the overhead of launching. AppleScript Studio does not create compiled scripts, but only applications.

Furthermore, AppleScript Studio's reason for being is its ability to provide a full-featured user interface for AppleScript applications. Apart from FaceSpan, Script Editor and the third-party tools do not provide for a user interface for scripts, other than the simple Display Dialog command and a handful of similar commands in AppleScript itself. These tools are designed for writing scripts, not for writing full-featured applications. They are more suitable for doing so than AppleScript Studio.

The argument that AppleScript Studio is overkill for many scripts is not limited to simple, short scripts. Many scripts that have no significant interface are extremely complex, to the point where the advanced debugging and other capabilities of a tool like Script Debugger are not just useful but essential. Yet, because they require no significant user interface, such scripts are more conveniently written using a tool designed for and focused on that task.

What, then, of FaceSpan? FaceSpan is a powerful visual application builder for AppleScript applications. It was originally distributed by Apple itself in 1993 as Frontmost. Its manual was entitled "AppleScript - Building Interfaces." As mentioned above, it is a classic Mac OS application which builds applications that run on the classic Mac OS, so at the very least it fills the gap left by the fact that AppleScript Studio is for Mac OS X only. But it is rumored that FaceSpan is being ported to Mac OS X. Why would you use FaceSpan instead of AppleScript Studio on Mac OS X? In my view, there are some good reasons, depending mostly on where it is you want to go and how much effort you are willing to put in to get there.

One reason for using FaceSpan in preference to AppleScript Studio, I think, is that the FaceSpan interface for building applications is easier to use than that of AppleScript Studio. This is undoubtedly an area where reasonable people can disagree, but I find that the FaceSpan interface is more intuitive. I say this as someone who has a lot of experience using Interface Builder for Cocoa application development, as well as years of FaceSpan experience, so my views aren't a result of being more familiar with one than the other.

To put it most accurately, I find that the FaceSpan interface more closely reflects the essence of an object-oriented approach to building AppleScript applications. This has mostly to do with the fact that, in FaceSpan, script handlers usually reside within the specific user controls with which they work. Except for the main project script, a FaceSpan application consists of window, button, and other user control objects, each of which contains its own script handlers to carry out its functions. This organization is made visible in FaceSpan's user interface by such devices as a script button that is enabled when you select a user control that has an embedded script; click the script button, and that object's script handlers open in an editing window plainly associated with the object.

AppleScript Studio applications can be built, to be sure, in much the same way. Although the main AppleScript Studio tutorial emphasizes putting most of an application's script handlers in a single main application script, the manual points out that you can put them in multiple scripts more closely associated with individual user controls. Several of the provided example applications do this. But, even when you put handlers into individual scripts associated with specific user controls, AppleScript Studio's user interface does nothing to emphasize the relationship. You will need hands-on experience with AppleScript Studio to appreciate this, but the Info window for a specific user control, while listing a number of event handlers implemented for that specific kind of control, also contains a scripts area at the bottom that lists all available scripts in the application. You can pick any one of those scripts as the place to write the handler for the specific user control. It is only the developer's disciplined and voluntary adherence to descriptive naming conventions that will make the object-oriented nature of an application clear. FaceSpan, on the other hand, makes it very obvious that the handler belongs in that one user control's script.

The upshot is that, in my view, a relatively straightforward AppleScript application with a "real" application-like user interface can be built somewhat more easily with FaceSpan. I have my eyes open, however; it may be that increased experience with AppleScript Studio will persuade me that it is the only solution I need for this purpose, after all, while the actual release of FaceSpan for Mac OS X might convince me that my first instincts are correct. One significant distinction is that FaceSpan lacks a debugger, although that element can easily be provided by integrating Script Debugger with FaceSpan. There is at least one other option, as well, although I haven't used it personally: REALbasic can be used to provide an application interface, and AppleScript code can be embedded to do the real work.

So we come to the question of what AppleScript Studio is good for. There are two answers, addressed to two different constituencies.

For the AppleScript community, AppleScript Studio is a highly sophisticated, powerful tool for building full-featured applications using AppleScript as its programming language. An AppleScript Studio application is a full-fledged Cocoa application having all of the mature NextStep, OpenStep, and Cocoa underpinnings that this implies. All of the details have been provided to enable you to build a proper Mac OS X application that will include all of the expected Mac OS X features, including such things as drag and drop editing, compliance with Aqua human interface guidelines, and so on.

Its development environment is vastly more powerful than that of FaceSpan. Project Builder and Interface Builder provide much greater control over the details of compiling and linking your application. And, whereas FaceSpan offers virtually no debugging support (except by allowing external editors having debugging capabilities, such as Script Debugger, to be used in place of the FaceSpan editor), the debugging capabilities of Project Builder are extensive and professional.

An AppleScript Studio application is a Cocoa application, having access to the enormous breadth and depth of the Cocoa Application Kit and Foundation frameworks. If AppleScript and the Interface Builder user controls are not alone powerful enough for your application, you can also use any and all of the built-in Cocoa classes and methods to augment them. Although I haven't yet tried this, you should also be able to make Carbon calls. Objective-C is a superset of the standard ANSI C programming language. It is commonly said that, if you already know C, you can learn the Objective-C extensions in a day or two. This requires "real programming," of course, but it means that, once you have acquired the necessary skills, you can take AppleScript Studio just about as far as you like.

For the Cocoa community, AppleScript Studio adds a fascinating new string to your bow. Just as an AppleScript application built with AppleScript Studio can include bits of Objective-C code, so an Objective-C Cocoa application can use bits of AppleScript. The only difference is one of degree, for you can intermix Objective-C and AppleScript to any degree. This means that, for functionality that isn't utterly dependent on the highest possible speed, a Cocoa programmer can use simple, plain-English AppleScript statements instead of using more complex Objective-C code to accomplish many tasks. (It isn't widely known, but there are a number of Macintosh applications that have for a long time relied on internal AppleScript statements in lieu of Pascal, C or other code for some operations.) There are even some tasks that can't be accomplished in Cocoa except by using AppleScript, such as getting the Finder's "Show Info" comments.

In addition, AppleScript Studio adds some capabilities to Cocoa applications that weren't available before. Chiefly, it enhances a Cocoa application's scripting terminology dictionary to include not only the built-in suites that were already part of every scriptable Cocoa application, but a whole raft of user interface suites that make it possible for a scripter to manipulate and control the user interface of a scriptable Cocoa application. While AppleScript has always focused more on scripting the data than on scripting the user interface, there are occasions when it is useful to be able to script the interface. One of those areas is in quality assurance. A Cocoa programmer can now write AppleScripts to automate the testing process of a Cocoa application, using these new AppleScript terminologies. Another area might be in building automated demonstration scripts for use as part of an application's documentation or in tutorials.

I'm looking forward to Apple's having a great success with AppleScript Studio.

Bill Cheeseman is a retired lawyer now making his living as a Macintosh developer and loving every minute of it. He is uniquely qualified to write about AppleScript Studio, having served as webmaster of The AppleScript Sourcebook (www.AppleScriptSourcebook.com) for many years and having also written a Cocoa tutorial, Vermont Recipes - A Cocoa Cookbook (www.stepwise.com/Articles/VermontRecipes/).