Actions

The notification system used by UI Actions is designed to send out notifications for common events, such as opening, closing, and resizing of windows; opening and closing of menus; selection of menu items; activation and deactivation of applications; and things like that. These notifications are “free” for Carbon and Cocoa applications, so pretty much everything should support them. Application authors can add additional notifications to their programs, but there’s essentially no way to discover these additional notifications if the developers do not supply a list of them to their users.

These notifications are the events that trigger your UI Action scripts.

Notifications would be sort of useless if you had to respond to every notification you receive, so you can also choose to respond to notifications that match a given filter. Additionally, you can apply your own filtering in your AppleScripts.

One of the first things you need to understand about notifications is that they typically don’t get sent until after the triggering application has completed the associated event. This means that you can’t write UI Action scripts that replace the functionality of an application. This is a little disappointing, but understandable.

My first idea for a UI Action script was to augment Safari’s “View Source” command so I could view and edit the source in BBEdit. I already have an AppleScript that lets me view the source code for the current Web page in BBEdit, so I figured it would simple to modify the script to work as a UI Action script. All I’d need to do would be close the source code window that Safari opened, paste in the existing AppleScript code, and use the UI Actions Setup application to attach my script to the “View Source” command.

These first steps went smoothly enough, so I selected “View Source” from the View menu. Success!…or at least it seemed. I tried this a few more times and I noticed that it was taking longer and longer for my UI Action script to run. Sometimes, I’d get impatient and close the source code window myself. Then, my script would finally run and close the browser window, since that was now the frontmost window. Rebooting my computer seemed to improve the situation, but the notifications seemed to bog down the longer my computer was running. If I had to guess, I’d say this is probably an issue with Panther’s notification system, but I could certainly be wrong.

Speed wasn’t the only issue that impacted my View Source UI Action script. While the script was eventually triggered when I selected “View Source” from the View menu, it was never triggered when I used the Command-Option-V shortcut. I did a little digging and found that support for keyboard shortcuts for menu items was a bit spotty. In the Finder and in BBEdit, I was able to trigger UI Action scripts for menu items using the associated keyboard shortcuts. In Safari, MarsEdit, and iTunes, the keyboard shortcuts did not trigger any associated UI Action scripts. Again, I suspect the problem lies in Panther’s notification system, as opposed to UI Actions. However, this shortcoming severely limits UI Actions’ usefulness.

UI Actions Setup

As I mentioned earlier, there are two ways to attach AppleScripts to UI Actions. The first is through the UI Actions Setup application and the second is through the AppleScript interface.

If you’re developing UI Action scripts that you want to install on multiple machines or for multiple users, you’re probably better off using the AppleScript interface. In that case, you would simply install the necessary AppleScripts on each computer and run a setup script to attach them. Depending on how you distribute the AppleScripts, you could possibly integrate the entire process into an installer.

If you’re simply attaching AppleScripts to UI Actions on your own machine, you probably don’t want to write setup scripts for each and every UI Action. This is where you would use UI Action Setup.

Configuring UI Actions with UI Actions Setup

On the surface, the interface seems simple enough. The main interface is an outline that shows you applications that have UI Action scripts connected to them. You can expand the outline to see which notifications your scripts are monitoring, which AppleScript will be run, and which filters are applied to the notification for the given AppleScript. You click the + button to add an entry to the outline and the - button to remove an entry. The “Reveal in Finder” button will, appropriately enough, show either the selected application or the AppleScript in the Finder, and the “Edit Script” button open the selected AppleScript in your script editor of choice.

Once you start using UI Actions Setup, you will quickly realize it’s nowhere near as simple as it looks. To be honest, the interface does some downright strange things. I found it quite counter-intuitive at times and frustrating.

When you want to add a new UI Action script, a sheet appears and you supply the application you want to monitor, the notification for which you’re listening, the AppleScript you want to run, and the filter, if any.

The only way to choose your application and your AppleScript is via a standard file choose dialog. Drag and drop would be a nice option. Also, I would love if there were a menu of running applications. Navigating to your application isn’t too much of a burden, but this feature would keep me from needing to remember that the Finder is actually located in /System/Library/CoreServices.

I’m a little disappointed by the filtering options. It appears that your filter text needs to be an exact match, including case. As far as I can tell, you cannot filter anything with dynamic text, like the Copy and Undo commands in the Finder. This also presents problems when dealing with menu items that contain leading spaces, like many of the entries in Safari’s View menu.

UI Actions Setup gives you the ability to disable some or all of your UI Action scripts. You can disable all the scripts by deselecting the “Enable UI Actions” option at the top of the UI Actions Setup window. In the notification outline, you can choose to disable notifications or scripts—so, you could turn off all of your Application Activated scripts, but only disable a subset of you Sheet Created scripts. Unfortunately, there’s no visual indication of whether or not a script has been disabled by something further up the event hierarchy. If you deselect the “Enable UI Actions” options, the entire outline should appear grayed-out. If you deactivate a notification, any AppleScript triggered by that notification should be grayed-out.

At one point, I spent nearly 10 minutes trying to figure out why a UI Action script didn’t appear to be working the way I intended. Both the notification and the script were enabled. Eventually, it dawned on me that I’d turned off all the UI Actions. If the user interface did a better job of relaying this information, I would have realized my error much quicker.

Instead, UI Actions Setup apparently uses grayed-out text to indicate text that cannot be double-clicked: application names and script names appear in black, notifications and filters appear in gray. I’m afraid I just don’t understand this design choice.

Editing and removing filters on existing UI Action scripts is also problematic. Basically, you can’t edit a filter once it’s been placed; you have to remove the existing filter and add a new one. That’s a little harsh, especially if you just want to fix a typo. Furthermore, if you remove the last filter from an AppleScript, it doesn’t clear the filter; it removes the script! If that was the only script attached to a notification, it removes the notification! If that was the only notification…well, you get the idea. To remove the last filter from a script, you need to add the AppleScript to the notification with no filters. The whole process seems a bit backwards to me.

All of the options available through the UI Actions Setup window are also available through the “UI Actions” menu… except there are no keyboard shortcuts for any of the commands. I suspect that there’s a decent amount of overlap between the group of people willing to write their own UI Action scripts and the group of people that prefer the keyboard to the mouse, so I don’t get why these shortcuts were omitted.

UI Actions Setup does have one rather nice touch for dealing with notifications—you have the option of viewing the notifications with their official, Apple-supplied names or their more readable English translations. The official names aren’t impossible to understand, but English translations are certainly more readable. Like my fourth-grade teacher tried to drill into my head during penmanship class, things are a lot more readable when there are spaces between the words.

Documentation

I found the UI Actions documentation a bit sparse. There was one document that went over the basics of writing UI Action scripts, a pair of documents listing the valid notifications and roles, and a number of AppleScripts showing what struck me as some fairly basic functionality—responding to application activation, window switching, and menu commands. The scripts integrating UI Action scripts with GUI Scripting could be useful, since GUI Scripting opens up additional possibilities. There was also one AppleScript that dealt with UI Actions over a network, which struck me as interesting, though I wasn’t able to attempt anything along those lines.

The reason I felt the included scripts were fairly basic was because they seemed like little more than notifications combined with filters. I’d hoped to write a UI Action script that would make a backup copy of my weblog entries whenever I clicked the “Send to Weblog” toolbar button in MarsEdit, but after much trying, I wasn’t able to figure what combination of notifications, filters, and AppleScript would let me identify a toolbar button by name.

Final Thoughts

Although my experience with UI Actions has been somewhat lacking, I’m still excited by the basic premise and I hope that continued development on both the UI Actions software and the underlying operating system will lead to an improved user experience. It seems as though the folks at PreFab Software feel the same way—while I was preparing this review, I was informed that an upgraded version of UI Actions will be released once Tiger is available and that this upgrade will be free for owners of the current version.

If you have a need for UI Actions today, you need to figure out whether you can accomplish your goals, given the current state of things. PreFab offers a 30-day demo for UI Actions, so if there’s something that you need to do and you know that UI Actions is the best way to get it done, get the demo. If you get everything working to your satisfaction, then I suspect you will become a very happy customer.

If you’re like me and think that the idea behind UI Actions is insanely cool, but you’re not exactly sure about how you’ll use the technology, you might want to wait a bit.