AppleScript_ The Definitive Guide - Matt Neuburg [19]
If an applet behaves like the script it contains, why would you bother to make one? Why not simply leave the script as a compiled script file? One reason would be that you want the script to run in some context where merely opening a compiled script file would not run it. One obvious example is the Finder. Let's say there's some operation you frequently need to perform, and the way you want to perform it is by double-clicking something in the Finder. Perhaps you find the Script Menu too much trouble; perhaps you like having an icon right on your desktop, where you can see and access it easily by double-clicking it. Or perhaps you don't want it on your desktop; perhaps you'd like to put it in the toolbar area of your Finder windows. (The toolbar is the area of a Finder window above the files but below the titlebar.) Single-clicking a toolbar item is exactly like double-clicking the same item on the desktop or in a Finder window. But double-clicking a compiled script file in the Finder doesn't run it; it opens the script for editing in a script editor application. On the other hand, double-clicking an applet (or single-clicking it in the toolbar) does run the script. (Indeed, Apple provides, at http://www.apple.com/applescript/toolbar, some example scripts for you to put into your Finder window toolbar, and guess what? They're all applets.)
Similarly, suppose you have a script that you'd like to run automatically when you log in to your computer. To run things automatically when you log in, as you doubtless already know, you put them into the list of Login Items in the Accounts preference pane. But it's no use putting a compiled script into that list; this is not an automatic location, where a compiled script, if found, will be run. The Login Items list is not, for example, like BBEdit's Startup Items folder discussed earlier in this chapter. What the Login Items list expects is an application. Well, you can turn a script into an application by making it an applet; so that's what you do.
Another advantage of applets over compiled scripts is that an applet can be a droplet —an application onto which you can drag and drop Finder items (files and folders) in order to process them with your script. An example appeared in "Calculation and Repetition" in Chapter 1.
AppleScript Studio
A compiled script or an applet has essentially no user interface. Your script can present a few basic dialogs for the user to interact with (as explained in Chapter 21), but that's all. This is usually not a problem, but sometimes it would really help to have some slightly more sophisticated user interface.
In this situation, AppleScript Studio can be helpful. AppleScript Studio is a way of writing a standard Cocoa application, with Mac OS X-native windows and interface widgets, when the only programming language you know is AppleScript—there is no need to know Objective-C, the default Cocoa programming language, and you don't need a very extensive understanding of the Cocoa application framework. AppleScript Studio doesn't give you direct AppleScript access to everything that Cocoa can do, not by a long chalk; but it can be an easy and rapid way to wrap an interface around some AppleScript code.
For example, Figure 2-8 shows an AppleScript Studio application containing a window that lists the user's hard disks. Here's the code:
on awake from nib theObject
tell application "Finder"
set L to (get name of every disk)
end tell
set content of table view 1 of scroll view 1 of window 1 to L
end awake from nib
Figure 2-8. A Cocoa application written with AppleScript Studio
That's all there is to it. The code is recognizable AppleScript; indeed, within the awake from nib handler, the first three lines are essentially the same as the script in Figure 2-1, asking the Finder for the names of the disks. The only addition is the fourth line, starting with set content, which populates the interface with the Finder's reply.