TidBITS: Mac Macros

Series: Mac Macros

Automation programs that can add speed, precision, and utility to your daily life

Show the full text of all articles

Article 1 of 9 in series

09 Dec 1996 | Print

The User Over Your Shoulder - Of Macs and Macros

by Matt Neuburg

Hide full article

TidBITS not long ago discussed three macro programs: QuicKeys (beginning in TidBITS-347), OneClick (in TidBITS-350), and KeyQuencer (in TidBITS-351.) Consideration of these has led me to some reflections on the state of the Mac. In the best of all possible worlds, I think, we wouldn't need macro programs at all: the Mac would be easily scriptable without them. Until then, macro programs offer much-needed relief.

The Prison and the Promise -- Here's the problem: our software still rules us instead of the other way round. My Mac, full of "Grand Unified Applications" that compel me to adjust my work habits to their structures and my needs to their feature sets, sometimes feels more like a lair of corporate priests than a liberation of my individuality. The Mac has fallen short of the promise of Apple's famed "1984" commercial: despite the supposedly user-driven event loop, we remain prisoners of modalities and restricted choices.

One escape would be to write your own applications, but that would involve unnecessary reinventing of the wheel. (I do think the Mac ought to be much easier to program, but that's another story.) For most operations, programs you already own can probably perform all the needed tasks - if only they better understood your needs, or you could combine them as desired.

For example, a dozen times a day, after some Find-and-Replace operation with Nisus Writer, I press Command-S and nothing happens. Why? I'm watching the document, but the Find/Replace window is frontmost, and in Nisus Writer that disables the Save command. Now, wouldn't you think that after a while, the computer would get the idea? "Say, Matt, I notice you keep hitting Command-S with the Find/Replace window frontmost. I've been wondering - are you doing that because you'd like me to save?" Alas, the computer probably won't talk (or think) this way any time soon. So, if a program doesn't work as you want, you should be able to customize it.

[The closest attempt to this sort of agent technology is the shareware Open Sesame from Charles River Analytics, but in my testing in the past it never made any useful suggestions. If you're interested in programming by demonstration, check out Allen Cypher's Eager demos. -Adam]

<http://www.cra.com/products/sesame/ sesameinfo.html>
<http://www.atg.apple.com/Allen_Cypher/Eager/ Eager.html>

Mapping the Mess -- The ability to customize programs is not built into the Mac. Rather, each program's developers must write it in such a way that its functions are exposed to public control. Loosely speaking, this makes the program "scriptable."

But no standard for customizability has taken hold. In the Mac's early days, Apple lobbied developers to accept uniformity by voluntary convention: make windows look like this, make menus work like this, make dialogs work like this. They succeeded so well that Apple's Human Interface Guidelines significantly informed the look and feel of Windows and other graphical interfaces. But Apple did not insist upon scriptability, even after System 7 made it easier.

As a result, developers often don't grasp the importance of scriptability. The MACSCRPT mailing list is a place to watch veteran scripters slapping their virtual foreheads in anguish over developers who don't "get it" - such as when a major developer challenged readers to persuade them the next version of their program should be scriptable. (If you're interested in subscribing to the MACSCRPT list, send email to <listserv@dartmouth.edu> with the command "subscribe macscrpt <your full name>" as the body of the message.)

I take it as axiomatic that a computer is meant to be programmed, and so ideally every program should be scriptable. But how and how much you can customize a program's behavior varies immensely. Some programs expose all their functionality, some expose only a fraction, and some expose nothing. Then there's the "platform" from which a user is enabled to command an application: a program may include its own internal scripting language, respond to commands via the Mac's messaging system (Apple events), or a mixture of both. Then there's the degree to which one may detach the program's interface from its functionality; for example, menus or dialogs might be customizable, or a program could perform tasks behind the scenes rather than in a window or in the foreground.

You can probably think of other measures of scriptability. The point is that if we made a scriptability map, existing programs would be scattered all over it. For instance, Microsoft Word 6 exposes all of its functionality through an internal scripting language (and some of it to Apple events as well), lets you customize menus, and even build new interface elements such as custom dialogs and palettes. Nisus Writer 4.1 only exposes some of its functionality through an internal scripting language (and not at all to Apple events), and its interface is only minimally customizable (keyboard shortcuts can be changed). MoviePlayer isn't scriptable. And so on.

Scripting in Tongues -- The Word 6 model of complete scriptability is the exception rather than the rule: scriptability in general is frustratingly incomplete. Nisus Writer won't tell me the font or style of the current selection, and I can't tell Eudora to select message so-and-so without opening it. Word's degree of interface detachability (where I get to decide what each of its menu items does) is even rarer - perhaps Mac OS 8 will make writing this style of application easier, but I'm not holding my breath. There are also internal scripting languages which can't be hooked to other programs at all: it's maddening.

Still, suppose that every internally scriptable program also had an external hook, so scripts written in an internal scripting language could at least be sent from another program. You might think that external scriptability would be better, because every internal scripting language is different (and may not be very good), whereas external scriptability can be based on one language, such as AppleScript. However, many internal scripting languages are superb (like Excel's Visual Basic), and, almost paradoxically, AppleScript-savvy programs can each introduce their own AppleScript syntax, so scripting those programs is still like learning a new language - or even harder because the syntax usually isn't obvious or documented. (How often I've seen letters to the MACSCRPT list from people stumped on how to make Eudora delete the selected message: the magic AppleScript formula 'move message 0 to end of mailbox "Trash"' isn't obvious.) Plus, external scriptability doesn't solve the fundamental problem: you're still at the mercy of any particular program as to how much functionality it chooses to expose.

Macro Management -- Customization should permit you to link a program's existing functions in new ways. It should also allow you to incorporate functions of other programs, combining the strengths of each in a milieu which can sense and respond to the state of each program, draw upon the power of the system as a whole, and support some basic programming using common types of information (such as numbers and text).

Until scriptability is more uniform, a system-level macro program is the best central command post for customization. The downside to system-level macro programs is that, no matter how well-engineered, they have the potential to expose problems and bugs in other programs or system extensions. For instance, if an application has troubles with window management, displaying a palette or a dialog box with a macro program might cause problems - even if the macro program does everything by the book. Nonetheless, a system-level macro program can type, click the mouse button, choose from menus, and generally simulate user actions so as to drive most non-scriptable or partially scriptable applications. It can intervene in normal operations, respond to user actions such as keystroke commands, deal with system information (such as what windows are present, what's on the clipboard, what files are in a folder), and talk back and forth with other scripting environments. Plus, ideally, it has genuine programmability, preferably in some easy but flexible form.

Of the three macro programs we looked at in TidBITS, WestCode's OneClick is the most programmable: its intuitive, elegant language has lots of user-simulating power, system-level functionality, and programming constructs. A comparison with HyperCard is apt because OneClick is more than just a macro program: it's a mini programming environment. The buttons you place on its palettes respond to clicks, display menus, and respond to your choices. Plus, OneClick buttons can accept text files via drag & drop; show or hide themselves; and display icons, textual information, or progress bars.

I currently resort to OneClick whenever the question pops into my mind, "Why can't this program do this?" For instance, Eudora's filters don't include an option to automate saving messages as text files based on their subject or sender: it was easy to write a OneClick button that does so. In Nisus Writer, I always had to peek at several menus to find out the font, size, and styles of the current selection: now, I have a OneClick palette that always displays that information textually. These are things that QuicKeys could never have done for me, so I've been able to dispense with QuicKeys (and other utilities as well).

<http://www.westcodesoft.com/>

Still, OneClick requires some compromises. Like other system-level macro programs, it operates at a low level and can come to loggerheads with some applications and extensions, at least on my machine. It's also somewhat in its infancy; that's great if you want to participate in the excitement of its evolution or invest time in developing your own tools, but right now it may not have the pre-made functionality you want.

KeyQuencer is the best choice for those who want a simple interface and minimal RAM requirements, or who particularly need some of its functions (such as its remote control of other machines, printer selection, cursor animation, and so forth). Binary Software, like WestCode, is very responsive to suggestions, so this is another chance to involve yourself in a program's growth process.

<http://www.binarysoft.com/keyquencer/ keyquencer.html>

For those who prefer something rather more tried and true - or would rather not learn a text-based language - QuicKeys remains an important option. Its use of dialogs and recording helps the user assemble functionality without feeling like any programming is going on. What's more, QuicKeys has been around and solid for a long time, and has learned to deal with many non-standard system extensions and user interfaces, though support for the product at CE seems to have weakened to a trickle.

<http://www.cesoft.com/quickeys/qkhome.html>

The important thing is that you can and should have a macro program so that you, not your computer, are boss. It's great so many options are available now, and you can't go really wrong with any of these programs. They can all drive unscriptable programs, they can all use Apple events to cooperate with scriptable ones, and they're all affordable. Your preference will ultimately be a matter of personal style or need. Treat yourself to one as a holiday present! You can even get more than one and combine them. Whatever you do, take control of your computer: don't let 1997 be like 1984.

DealBITS -- Cyberian Outpost's deal on KeyQuencer for $33.95 ($4 off) is still available from the URL below. Note that this page doesn't explicitly say it's a deal, but it is.

<http://www.tidbits.com/products/key- quencer.html>

Also, WestCode Software has set up a deal on OneClick for TidBITS readers. You can purchase it for $59.98 ($10 off regular WestCode pricing) through the URL below:

<http://www.tidbits.com/products/one-click.html>

Article 2 of 9 in series

30 Sep 1996 | Print

Form, Function, and QuicKeys 3.5, Part 1

by Matt Neuburg

"The question is," said Humpty Dumpty, "which is to be master - that's all." - Lewis Carroll Perfecting the relationship between form and function is no easy thing for a software developerShow full article

Hide full article

"The question is," said Humpty Dumpty, "which is to be master - that's all."
- Lewis Carroll

Perfecting the relationship between form and function is no easy thing for a software developer. To be sure, no amount of graphical bells and whistles can compensate for flawed functionality. Nevertheless, there's no denying that interface makes a difference - a huge difference. No matter how valuable a particular feature, if triggering its performance involves steps too numerous, obscure, counter-intuitive, repetitive, annoying, or daunting (for reasons rooted in the peculiarities of the human psyche), people won't use it, or (if they must) they'll dislike it.

CE Software's QuicKeys (QK) first appeared in 1987; TidBITS has been mentioning it since version 2.0 came out in mid-1990 (issue #16!). [In part, this is because QuicKeys played an invaluable role in the weekly distribution of TidBITS for our first five years. -Adam] Its function is to help you get round the formal shortcomings of other programs. It's splendid that CE has recently promulgated QK 3.5, even though 3.5 is primarily an "interfacelift." The current version, 3.0, has been in place since mid-1993. In this first part of a two-part article, we'll provide a general description of QK 3.5; next week, we'll put this upgrade under the microscope.

Baby, You Can Drive My Computer -- QK's function centers on an extension which can perform certain fundamental Macintosh actions - hit a key, choose a menu item, click or drag the mouse, open a file - as if there were an invisible user at the controls. Its form comes from the various ways you can access, or trigger, that functionality, such as by pressing a certain keystroke, and from the dialogs that let you configure QK by associating a particular trigger with a particular action.

Why is this useful? Four main reasons come to mind. But, before I describe them, I should explain that a QK action is either "universal" to the computer as a whole or specific to a particular application. An application-specific action and its keystroke are available only when that particular application is frontmost. This means the same key combination can be used to trigger different QK effects in different applications, or a keystroke can invoke a universal action regardless of the application. You can have application-specific keystrokes override or nullify universal ones: thus, a universal keystroke could be made to apply to all but one particular application.

The first use of QK would be to customize an application so that it behaves more like other applications, reducing the number of different keyboard shortcuts I must memorize. For instance, I sometimes use an application which does not use Command-W as the keyboard shortcut for closing the frontmost window; instead, it uses it to mean Save. But I have a habit of using Command-W to mean Close, and Command-S to mean Save. So, I set up QK so that, in this application, when I hit Command-W, QK closes the window (by clicking its close box), and when I hit Command-S, it saves the document (by choosing the Save menu item).
Secondly, sometimes QK can perform a basic function that an application cannot. For instance, some applications have no menu command to move the frontmost window to the back, bringing the next window to the front. QK can perform this action in any application, so I can use the same keystroke to perform it universally.
Third, substituting a keystroke action for a mouse action saves me both time and muscle strain. Many applications lack a command to scroll the window up or down, or jump to the start or end of the document; one must click in the scrollbar. With QK, I press a key, and QK does the clicking.
Fourth, QK can string actions together. Such a string is called a "sequence." Where you find yourself performing the same set of actions repetitively, QK may be able to perform them for you. Are there certain phrases which, for one reason or another, you often use in your email? A single action from you, and QK can type any of them. Do you sometimes need to silence your computer quickly? You hit one keystroke, and QK opens the Sound control panel, chooses Volumes from the pop-up menu, clicks the Mute button, and closes the control panel. Are there certain combinations of font and size that you frequently use? No need to select twice from the menubar each time you change; you perform one action, QK does the rest.

Sequences can help you circumvent an application's irritating interface, too. When I used CE's QuickMail 3.5, the steps required to address a new message to go out over the Internet were numerous and tedious; as I recall, you had to ask to address the email, click the "special" button, type something in the "first name" box, replace the contents of the "server" box with "Internet", type the address in the "address" box, click OK, and click OK again. With QK, a single keystroke triggered a sequence that created and addressed a new Internet email from the contents of the clipboard.

Hiyo, Trigger -- Sooner or later you will run out of easily remembered keystrokes to serve as triggers; and over the years QK has evolved various additional types of triggering event.

One of these is Time: the action is performed in response to the arrival of a certain moment. Time, for QK, can be reckoned absolutely or in seconds from the startup of a particular application (or the Mac as a whole). Using absolute reckoning, you might have your Mac perform unattended routine actions, such as running a disk optimization or a backup once a week late at night. Using application-relative reckoning, you might automate responses to an application starting up, like clicking away a splash screen or dialog.

You can also trigger actions by choosing from a special QuicKeys menu. This menu can appear hierarchically in your Apple menu, in the menubar, and/or as a pop-up menu. You decide which QK actions should appear in the menu, and at any moment the menu limits itself to universal actions plus those specific to the frontmost application.

There is also the reference card, a QK action which, when triggered, displays a modal dialog containing all currently available QK actions; clicking one triggers it. The reference card is also good for reminding you of specific keystrokes for actions (the QK menu listing doesn't).

You can also create a tiny double-clickable application to trigger a QK action; such an application is like an alias, and can be located and started up in the same convenient ways.

In mid-1992, QK 2.1.2 introduced a new type of trigger, SoftKeys. This was itself a QK action which, when triggered, displayed a previously configured modal dialog consisting of ten buttons, numbered 1 through 0 as on the top row of your keyboard, plus the name of a QK action written next to each. Clicking a button or typing the corresponding number-key dismissed the dialog and triggered that QK action. Since the QK action triggered through a SoftKeys dialog might be to put up a different SoftKeys dialog, you could have a series of such dialogs referencing one another until you reached the action you actually wanted to perform. SoftKeys was supposed to bring your various QK actions under a convenient category-based control, but in reality it was horribly reminiscent of those DOS-based successions of modal "menus" that many of us switched to the Mac to escape from in the first place.

In 3.5, QK has wisely abandoned SoftKeys, and sensibly implemented toolbars take its place. Toolbars can be universal or application-specific; an application can have multiple toolbars. You can customize the icons, and there is "hot help," with the name of the QK action appearing when the mouse is over its icon. Toolbars come in three types. The first two are "floating" (windoid) and "embedded" (movable but docked to the edge of the screen); their visibility can be toggled by a keystroke or in the QK menu (the floating type can also be clicked away), and is contextual in that a visible application-specific toolbar vanishes when you leave that application and reappears when you re-enter that application. The third toolbar type is "click-and-go," which behaves more like SoftKeys did: you must invoke it to make it visible, and it vanishes when you click an icon.

Some Mac users have strong negative feelings about toolbars in general, but no one is compelled to use this feature; others will surely welcome the capacity to add powerful customized toolbars to any application. I hope users will be able to navigate the toolbar editing interface, though; it's confusing and clumsy. For instance, you can't create or edit an action while you're working on a toolbar; and you're able to install in a toolbar destined for one application an icon for an action belonging to another application (clicking it does nothing).

Cliffhanger -- So much for what QK 3.5 does. But what about what you must do to configure it? How well does QK fit in with other ways of driving your Mac, such as AppleScript? And how good is 3.5 as an upgrade? Find out when this article continues next week!

Article 3 of 9 in series

07 Oct 1996 | Print

Form, Function, and QuicKeys 3.5, Part 2

by Matt Neuburg

Last week in TidBITS-347, the first part of this article described CE Software's QuicKeys (QK) and mentioned a new feature of the recent 3.5 release: toolbar triggersShow full article

Hide full article

Last week in TidBITS-347, the first part of this article described CE Software's QuicKeys (QK) and mentioned a new feature of the recent 3.5 release: toolbar triggers. Here, we conclude with some serious evaluation.

Creative Constraint -- For QK to be usable, the process of creating or editing a QK action must be simple and convenient. You want to spend your time using the computer, not configuring a program that makes it easier to use. Many actions are going to be spur-of-the-moment, ad hoc creations; if you're copying a series of pictures to the Scrapbook, you won't add automation to the process unless that's faster and more convenient than just finishing the job by hand.

Nonetheless, QK users over the years have had to put up with varying degrees of inconvenience and confusion in the interface used to create and edit actions. QK actions come in various types, and the desired type must be chosen from a poorly structured hierarchical menu. Many action types are created and edited via awkwardly designed dialog boxes, which often lead to other dialogs, all of which are modal and block one's view of things on the screen, including each other. (In 3.5, the main dialog is now movable and resizable, but it's still modal, and since windows behind it don't update, moving it is pointless.)

Once you've made a QK action, it isn't easy to know what it does without opening and editing it (and here come those dialogs again); you can't give an action an informative name. In some cases you can change its name, but you're limited to a few characters. In other cases you can't change the name at all. For example, an action that chooses the Close menu item and another that chooses the same menu item while pressing the Shift and Option keys (Close All in Nisus Writer) are both called Close. You can include a comment, but the comment isn't visible in the main window - you must click an action's comment icon to read it.

Assembling actions into sequences is even more daunting. In the sequence editor, you can't drag & drop an action to change its place in the sequence, and it isn't even intuitively obvious how move it by cut and paste. There's the same problem of non-descriptive action names, aggravated by the fact that there are no comments at all in the sequence editor! I don't understand why CE doesn't look at the interfaces of programs that do a successful job of letting you build sequences of editable action types; FileMaker Pro comes to mind.

For much of its history, QK sequences lacked any programming constructs, such as looping and branching; apart from calling one another (or themselves, infinitely), sequences were linear. Some clumsy if-branching appeared in version 2.1.2, and was much improved in 3.0. Version 3.5 improves the Jump command, and adds one new looping construct, the Batch Processor, which runs through all the files in a folder, opening each one and running a sequence on it. Note, though, that this won't help if what you need to do to each file doesn't involve opening it. All the branching commands remain limited as to what things QK is able to test for, and are clumsy and inconvenient to use.

OSA, Can You CE? History lesson: In 1991, System 7 introduced Apple events, which enabled inter-application communication (IAC) for those applications that understood how to send and receive them. In 1992, System 7.1 added the Open Scripting Architecture (OSA), which made it possible to create alternate programming languages that operated on Apple events. And in 1993, Apple released its own such language, AppleScript.

CE responded to System 7 by incorporating into QK 2.1 an extension, CEIAC (get it?), that allowed QK to send and receive Apple events. But bare Apple events are hard to use, and the important change came in mid-1993 when QK 3.0 made three major innovations:

It replaced CEIAC with a faceless background application, QuicKeys Toolbox. This application, among other things, responds directly to some useful AppleScript commands.
It added the ability to perform AppleScript scripts. Thus a QK action can be a place to store, and a way to trigger, an AppleScript script.
It included its own recordable OSA dialect. An application that executes OSA scripts (such as Frontier, HyperCard, or Apple's Script Editor) could now talk QK's language. Instead of triggering a previously defined QK action or sequence, it sends QK a script for the action or sequence. So, from within such an application, you can take advantage of QK's "invisible user" powers to script applications that aren't AppleScript-savvy.

For instance, I had an AppleScript script that copied multiple pictures from QuarkXPress and pasted them into Microsoft Word, but on the way I wanted to pass them through GraphicConverter to reduce their bit depth, and GraphicConverter isn't scriptable. So as my script handled each picture, it talked to Quark and Word in AppleScript, but in between, it talked in QK's language to make QK choose menus and click buttons in GraphicConverter.

Unfortunately, the integration between QK and other scripting dialects isn't very good, because QK has no variables, so it's hard to pass information back and forth.

For example, when I had to use Pegasus Mail, which was not scriptable, I wanted to make it automatically download each message in my mailbox from the Novell server to my hard disk, and then delete it from the server. With QK, I could select the next message and choose Save; but at this point I was faced with a blank Save dialog, and, lacking variables, there was no way QK was going to type a different filename for each message ("Temp1", "Temp2", etc.). So I had to drive QK from some other scripting application which could generate the successive filenames. I chose HyperCard. It worked, but it was tricky. On each pass through the loop, HyperCard had to let QK know the next filename; conversely, when all the messages were deleted, QK knew it (the "Save" button was no longer active), but it had to alert HyperCard to stop the loop.

Since I wrote that script, the world has progressed, but QK has not. I now handle such tasks with PreFab Player. Player has no interface: it isn't a way for the user to trigger actions and sequences directly, as QK is. But as a way for a scripting application to drive non-scriptable applications, it's better, because Player's commands are AppleScript or Frontier's UserTalk commands, so you can seamlessly use the variables and looping constructs of either of those languages; you don't have to hand any information across the OSA dialect boundary, or change dialects at all.

<http://www.tiac.net/prefab/player.html>

It Might Have Been -- For many years, QK has been a reliable workhorse in my Mac stable; I call upon it constantly to modify and automate my Mac's behavior. A computer, I am fond of saying, is to program; or at least, it is the user who should command the computer, not the other way round. QK has helped defend me from operations and application behaviors that smelt of inconvenience, of routine, of liturgical action and response, and that threatened to make me the automaton instead of the computer.

QK has long been acclaimed as a top-ranked, essential Mac tool. Yet CE was not content, in the past, to rest on its laurels. Successive releases of QK have always had an air of fiddling and tweaking, as if CE were seeking, while improving the experience of established users, to attract new converts by increased ease of use. QK 3.5, however, aside from the toolbars feature and the batch processor command, is basically a maintenance release. It's disappointing to think that, after a silence of three years, this is the best CE could come up with. In the interim, what else might CE have been doing?

CE might have resolved the nature and extent of QK's programming power. It might have improved QK's internal programming constructs, perhaps adding variables and arithmetic operations; conversely, it might have better integrated QK with existing scripting dialects. Instead, QK remains weak as an independent scripting tool and has been surpassed by PreFab Player as an AppleScript- or UserTalk-dependent one.

CE might have decided to educate and assist the user with improved manuals. Instead, the manual, which has gone steadily downhill since the sparkling clarity of the 2.0 edition (by the redoubtable Fred Terry), is now flimsy, ugly, poorly produced, skimpy, and uninformative; all printed reference information has been abandoned in favor of online help, which is in sluggish, clumsy, inappropriate Apple Guide format.

CE might have made 3.5 widely usable, but instead has cut off perhaps half the installed base by restricting this version to System 7.5 or higher.

CE might have increased QK's basic abilities. Here are some possibilities:

Allow QK's if-branching to "see" and test for a larger repertoire of features of a dialog. For instance, PreFab Player can see icons and read static text.
Allow QK to "see" the contents of a list box in a dialog, so it could select a particular item. To take an example: if you're using something like MacJanet, where you connect over the network to a server but not through the Chooser, you must bring up a dialog, pick a zone from one list, pick a machine from another list, then click OK and type your name and password. The list of zones and machines that are online changes constantly, so you can't automate this procedure unless QK can somehow read the lists.
Allow QK to take a screen shot within certain coordinates and compare it to a template. This would allow QK to "see" and test for graphic screen features it can't get at in any other way. Tempo (a rival macro program) and Ivy (a Virtual User plug-in) can do this.
Allow selection from a non-QK menu to be a trigger. For instance, Alessandro Levi Montalcini's NoDesktopCleanup can interfere when you select any menu item in any application, put up a confirmation dialog, and, if you click Cancel, prevent that menu item from carrying out its usual function. QK could expand on this technique, invoking an action or sequence before, or instead of, the application's response to its own menu. This would essentially make any application "attachable."

<ftp://mirror.aol.com/pub/info-mac/gui/no- desktop-cleanup-121.hqx>

Finally, CE might have made some genuine improvements to QK's interface. The new look of the main dialog and sequence editor is mere window dressing; what's needed is a rethinking of the interface, from the ground up.

In the End -- QK remains a staple; I can't imagine myself doing without it. QK owners running System 7.5 or later will probably wish to upgrade, if only to take advantage of any bug fixes I don't know about. However, after three years' hiatus, both new and long-standing users deserved a more full-featured release than 3.5 has turned out to be.

<http://www.cesoft.com/quickeys/qkhome.html>

[We hope to publish reviews of the main competition for QuicKeys, WestCode Software's OneClick and Binary Software's KeyQuencer 2.0, in the near future. -Adam]

CE Software, Inc. -- 515/221-1801 -- 800/523-7638

Article 4 of 9 in series

21 Oct 1996 | Print

OneClick - A Super Utility

by Steve Becker

Late last year, WestCode Software introduced OneClick, their answer to the need for a flexible, easy-to-use, comprehensive, highly customizable utility programShow full article

Hide full article

Late last year, WestCode Software introduced OneClick, their answer to the need for a flexible, easy-to-use, comprehensive, highly customizable utility program. OneClick incorporates some of the best features of Apple's Control Strip, QuicKeys, Square One, SuperClock, PopChar, PopUp Folder, and other utilities, integrating them into a single program with a low memory overhead, low price, and relatively low learning curve.

I have tried many Macintosh utilities over the years. In total, these programs cost a lot of money, resulted in extension conflicts, had overlapping feature sets in some areas, and still failed to provide all the features I wanted. I consider my computer needs to be fairly eclectic: they cover the gamut from word processing and email, to business accounting and trading stocks on the Web. My equipment ranges from a 68030-based IIsi to a Power Mac 6100/66. I've been extremely happy with OneClick, a single program that adapts to my wide-ranging hardware and software needs.

Nuts and Bolts -- OneClick consists of a single control panel that uses under 300K of RAM. After installing OneClick and restarting your Mac, you'll see a one-time, brief tutorial, as well as several Global palettes: the System Bar comes pre-configured with many useful buttons; the Task Bar displays buttons for each launched program; and the Launch Strip quickly opens anything that the Finder can open, including programs, files, and folders. OneClick also supports application-specific palettes that are only available when a particular program is active - including a pre-configured palette for the Finder as well as palettes for several popular applications (I particularly like the ones for ClarisWorks). You use the OneClick Editor to customize each of these palettes and to create more palettes - I'll talk more about that in a bit.

Palette buttons cause programs to launch, files to open, or scripts to run. Each button shows an icon, or text - or both - that indicates its function, so you don't have to remember key combinations. (You may assign keyboard shortcuts to buttons if you wish.) If a button's function is not self-evident, OneClick thoughtfully provides either Balloon Help or a less-obtrusive, yellow, pop-up description tag. It's easy to toggle either help option, and you can also edit the help text - a thoughtful feature.

Many OneClick buttons perform basic functions like Paste, Insert Date, Change Font (displays a pop-up list of available fonts in their actual typefaces - very neat), Change Font Size, Page Setup, Empty Trash, Make Alias, and Get Info. A small sampling of some of the more powerful buttons that come with the program includes Insert Character (like PopChar, this lets you select and quickly insert any character available in a given font), Glossary (create a glossary of commonly used bits of text and then quickly insert those bits; I use this button to create a signature glossary), Pop-up Hierarchical File List (shades of PopUp Folder), Pop-up Phone Book/Dialer, Pop-up Hierarchical List of files in the System Folder, Auto Save (at user specified time intervals), and Tile Windows. [Additionally, OneClick can use modules from Apple's Control Strip. -Tonya]

I think new users will find the basic buttons especially helpful. Even as an experienced user, buttons such as Insert Date, Change Font, and Change Font Size save me time. It is easy to create additional basic buttons, such as Print One Copy and Customized Page Setup (to apply pre-determined setup characteristics) - I use these with most of my applications. Some of the more powerful buttons like Insert Character, Hierarchical File Pop-ups, and Phone Book/Dialer replace entire utility programs and I find them a significant enhancement to my Mac's capabilities.

OneClick also adds a OneClick menu to the menu bar, though you can also access this menu from any palette. The OneClick menu lets you quickly show and hide palettes and switch to the OneClick Editor.

Customizing the Interface -- Using the OneClick Editor, you can create a new palette for any program, or modify an existing palette. To add a button to a new palette, you simply drag it from the OneClick Library to the palette, or you drag it from an existing palette.

In practice, the customization options for buttons and palettes appear nearly endless. You can assign any icon, or multiple icons, to any button; change a button's background color, size, and palette position (adjusted down to a resolution of one pixel); assign different styles to a button; and more. Similarly, palettes have a range of customization options, including background patterns and colors.

Although I like the tabbed organization and layout of the OneClick Editor, many features are not labeled and are not intuitive as to their use. Also, an Undo option is not available. WestCode is aware of these concerns and plans to address them in a future release.

Avoid Screen Clutter -- If you are thinking all these palettes cause screen clutter, WestCode has done a good job of preempting this potential problem. Palettes can be collapsed (iconified, in OneClick lingo) to a small icon with a single click. Many of the palettes can also be reduced to a small Title Bar. To hide all palettes, you choose Hide Palettes from the OneClick pop-up menu or press a keyboard shortcut. Palettes may also be configured as to their location on the Desktop and several other parameters. One possible enhancement in a future release will be an option to have a palette automatically get out of the way of the active window, so as to not obscure any part of it. [WestCode hopes to add this to version 1.5, due out later this year. -Tonya]

Be Creative -- If OneClick did nothing more than what I've already covered, it would be a fine program. In reality though, I've only begun to discuss what it can do. Just use the Record feature to make a button script for almost any action you perform with regularly with your Mac, and voila - you have a button that performs the recorded task.

You can record keys presses and actions like clicking a radio button or choosing a menu option. OneClick records such actions not in terms of mouse movements, but in terms of what you did, making for scripts that do not depend on the mouse being in a particular location when the script begins running. Once a script is recorded, you can edit it in the OneClick Editor window, which offers built-in help and error checking. I've encountered a few a situations where a program will not properly run a recorded action, but most of the time I've found recording to be easy, fast, and wonderfully effective.

If you know AppleScript, or want to learn OneClick's own (easier) EasyScript, you can create button scripts from scratch. If you are new to using a scripting language or programming, be sure to read the appropriate manual carefully.

[In addition, Matt Neuburg <matt@tidbits.com> notes "OneClick's language is spectacularly well thought out and easy to learn, with splendid data types and object-oriented messaging and a full battery of control structures. OneClick can gather all sorts of information about what's happening on your system, in real time, and make it available in fascinating ways. A OneClick button is programmable - you can drag & drop things onto it, press it with or without modifier keys, and have it react in different ways; it can display a pop-up menu for you to choose from. OneClick has superb abilities for communicating with other scripting milieus." -Tonya]

OneClick's Editor includes a basic graphics editor and the ability to borrow icons from other files. This, plus the ability to add text to a button's icon and create help text lets your buttons be self-descriptive.

I put my own words into practice. WriteNow is my favorite word processor, but the interface lacks toolbars. Combining the Record feature and the EasyScript Editor, I was able to create - okay, maybe I'm not objective about this - a terrific palette of buttons for WriteNow. Now WriteNow maintains its small memory footprint and quickness while providing me with the customizable toolbar features found in higher-end word processors like WordPerfect and ClarisWorks.

Warning -- This program should have a warning label attached saying "This program can become addictive." In addition to the customization features and productivity boosts - and the temptation to explore them fully- there is an active and helpful OneClick mailing list. (You can join the list through WestCode's Web site.) You'll also find a regularly updated collection of free buttons on WestCode's Web site (including my WriteNow palette, along with a few other palettes I made). In addition, a group of OneClickers has formed the Button Circle, where they regularly upload new freeware buttons.

<http://www.westcodesoft.com/>
<http://rhino.harvard.edu/dan/ButtonCircle.html>

The WestCode and Button Circle Web sites include palettes for programs like Eudora, Photoshop, Netscape Navigator, Emailer, and AOL, as well as buttons that provide an almost unbelievable array of features, such as saving multiple text clippings, printing selected text on or across pages, creating notebooks or address books, displaying available memory, and pasting quoted text.

Owning this program is like having your own personal utility factory. Its dynamic and flexible nature invites you to use your imagination in creating new scripts, or to just record common operations. If you don't think of yourself as the adventurous type, you can look forward to a free stream of buttons and palettes that others have created.

Some Commentary -- It is rare to find such an innovative program as OneClick. It eliminates the need for many other programs, uses little memory, adds only one extension to your System Folder, comes pre-configured with a large list of buttons that greatly enhance both the Mac OS and most of your applications, is regularly expanded through a steady stream of freeware buttons and palettes, is highly customizable to your individual needs, and it is fun to work with. To me, this program exemplifies much of what the Macintosh is all about - it empowers users to get much more out of their Macs while enjoying the experience.

Recently, Heidi Roizen (Apple VP of Developer Relations) gave an enjoyable talk at a BMUG (Berkeley Macintosh Users Group) main meeting, discussing Apple's new focus on needs of the developer community. WestCode represents a small, independent, innovative developer that is dedicated to working only on the Macintosh platform. I hope that both she and Gil Amelio put WestCode on their list of developers that will receive as much support as possible from Apple. In fact, bundling this product with Macs - or striking a deal to incorporate its technology into the Mac OS - strikes me as a way to further increase the benefit of the Mac OS over Windows. Also, though Mac OS 8 is still but a dream, this might breathe new life and excitement into System 7.x. In the meantime, other developers recognize the potential of OneClick; for example, the next version of Quicken will incorporate OneClick's Shortcut Technology into its Tool Bar.

Final Observations -- By now, you know that I am impressed with this product. Although most users report no or few problems with OneClick, I have encountered numerous bugs, most of which are fixed in the current 1.0.2 release. None of these problems resulted in data loss, and they have been worth putting up with in exchange for the overall benefits of the software. I have found WestCode technical support to be exceptionally friendly and helpful. The call is not toll free, but if no one answers your call immediately, you may leave your number and WestCode returns the call.

WestCode plans to release OneClick 1.5 later this year. Important enhancements center on more powerful Task Bar and Launcher palettes. A Task Bar button will display and launch recently used applications (think Apple Menu Options), and another Task Bar button will pop up the Launcher; especially useful should you keep the Launcher hidden. The new Launcher will be able to keep file sets, such as a separate Internet Applications set.

The street price for OneClick is around $75, and QuicKeys users can purchase a competitive upgrade for about $40 (the exact price depends on what version you have). OneClick requires System 7.0 or higher, and a 68020 or later processor.

[Steve Becker has been a BMUG member since purchasing his first Mac and runs his own Mac consulting business, MacEase, in Berkeley, California.]

[Those of you hoping to compare OneClick to its strongest competitors, QuicKeys 3.5, which we reviewed in TidBITS-348 and KeyQuencer 2.0, for which we have a review underway, should stay tuned. After reviewing all three products, we plan to compare them. -Adam]

WestCode Software -- 800/448-4250 -- 619/487-9200
619/487-9255 (fax) -- <westcode@westcodesoft.com>

Article 5 of 9 in series

28 Oct 1996 | Print

KeyQuencer - QuicKeys Quencher?

by Matt Neuburg

Those wishing to automate their Macs without spending the money or yielding the RAM required to run one of the big commercial macro programs may wish to consider KeyQuencerShow full article

Hide full article

Those wishing to automate their Macs without spending the money or yielding the RAM required to run one of the big commercial macro programs may wish to consider KeyQuencer. Once a $10 shareware program, the product of the ingenuity and generosity of the well-known Alessandro Levi Montalcini, it has now been upgraded to version 2.0 and sells as a commercial macro utility from Binary Software for $40. It runs quickly and cleanly in a small RAM footprint (less than 200K) under System 7.x, and most features are said to run (though without official support) under System 6.0.4 and later.

<http://www.binarysoft.com/keyquencer/ keyquencer.html>

What It's Like -- KeyQuencer macros live in "suitcases." The default suitcase loads at startup, and its macros (the active macros) can be triggered by a keystroke combination. Macros in other suitcases can't be triggered by a keystroke, but are available through a small application, KeyQuencer Launcher, which displays any suitcase as a double-clickable list. Macro names can be up to 31 characters, so the lists can be informative. You might leave the Launcher running all the time, with multiple suitcase windows open; your commonly used macros can be triggered with keystrokes, and if you need a less-frequently used macro (or if you forget an active macro's keystroke), there it is in one of the Launcher's lists. (Remember, though, the Launcher is an application, not a dialog or palette, so if you double-click a macro that affects the frontmost window, it will be the Launcher's window.)

This technique might help make up for the fact that in KeyQuencer, unlike QuicKeys or OneClick, there's no such thing as an application-specific macro. Once you've assigned a keystroke to a macro and made that macro active, that keystroke is unavailable for anything else, system-wide. It takes some planning to come up with keystrokes that have no meaning in any extension, control panel, or application. The danger is that you'll run out of possible keystrokes, or that you'll trigger a macro inadvertently. KeyQuencer installs itself with numerous macros already active, so before I knew it, I had accidentally stuffed a HyperCard stack while trying to read its stack script, and moved an important item into the Trash even though I wasn't in the Finder. A macro can check to see if a certain application is frontmost and either pass along the triggering keystroke or abort. Many of the pre-installed macros perform no such check, though, so be cautious.

Macros are created, edited, named, assigned keystrokes, and copied between suitcases in another application, KeyQuencer Editor. It's a simple, pleasant place to work. You don't have to "open" a macro to edit it: when you click a macro's name in the list, its contents appear in a word-processing pane for viewing and editing. Every macro consists of one or more text commands. You can type these commands, or you can enter them by double-clicking their names in a floating Commands window, which lists all commands and (when a command is selected) possible parameters. An online Help window updates dynamically with a description of the command's function and parameters.

The contrast between the whole milieu and that of QuicKeys couldn't be greater. QuicKeys has short macro names and confusingly arranged menus for selecting macro types, and editing happens in cascades of modal dialogs that must be completely dismissed before you can test a macro, discover that it doesn't work properly, and open everything up again. In KeyQuencer, both Launcher and Editor are applications, with normal windows - which, if you have about 700K of RAM to spare, you could leave open all the time. Editing is textual, and you can save the macro you're currently editing and test it without closing anything.

Communication -- There is no special KeyQuencer menu trigger, comparable to the QuicKeys menu; but James Walker's shareware OtherMenu, which is included, can trigger a KeyQuencer macro. Similarly, KeyQuencer has no time trigger, but if all you need is absolute time (as opposed to time since an application has started) you can use Chris Johnson's shareware Cron, which is also included. You can install a Control Strip module or NowTabs plug-in, from which you can choose and launch an active macro. You can talk to KeyQuencer from AppleScript or Frontier, including passing variables back and forth. Macros can even be incorporated into the CodeWarrior build process.

<ftp://mirror.aol.com/pub/info-mac/gui/other- menu-183.hqx>
<ftp://mirror.aol.com/pub/info-mac/cfg/chris- cron-10a7.hqx>

KeyQuencer can perform any of its functions on a remote networked computer that is also running KeyQuencer; you may, but do not have to, set up the desired functionality as a KeyQuencer macro on the remote computer. (I have not tested this.)

The Language -- KeyQuencer comes with about 260 pre-written macros; if you want to modify one or write a new one, you must use the KeyQuencer language, a rigid, hard-to-remember, command-plus-parameters idiom, where you just know you'll never wean yourself off online help and the reference manual.

In fact, it's not a language so much as a collection of commands. There are no subroutines: the only way to invoke one macro from another is to tell the first macro to type the second's keystroke. There are no looping, branching, or conditional constructs, but there's a Repeat command (that takes as its parameter a quoted string consisting of one or more macro commands) and commands that abort a macro if a certain application is frontmost or if two strings match. There are no arithmetic operators, but there's an Evaluate command which stores arithmetic expressions in the clipboard and a Counter command that maintains a temporary increment-decrement counter. There are no string-processing functions, but there's a clipboard-munging command that can do some. There are variables, but the syntax for passing them around is hair-raising.

To set A to 1 and B to 2 and then add them and put the result into C, you say:

SetVariable A "1"SetVariable B "2"Evaluate "\[a]+\[b]" copy -- this puts the result in the clipboard
SetVariable C clipboard -- this gets it out again

To type the numbers 1 through 10, each followed by a tab and a return, you say:

Repeat 10 "Counter increment save\rType $counter \q\\t\\r\q"

What It Can Do -- Every KeyQuencer command corresponds to a small file living in a folder (in your System Folder) called KeyQuencer Extensions. Removing one of these files from the KeyQuencer Extensions folder and restarting disables that command; adding a new one, if a new one is written, expands the repertoire of commands. (If there are commands you aren't using, disabling them lets you save still more memory; if you've just a few macros using just a few commands you can run KeyQuencer in less than 80K!)

There are the usual macro behaviors such as pressing a key, typing a string, choosing from a menu, clicking the mouse, waiting for various types of events. There are also extras similar to those in QuicKeys - and some rather more capable, such as changing applications or windows, setting speaker volume and monitor depth, choosing a printer, and mounting a server. There is a powerful Batcher application: for each copy you make, you preconfigure what macro it should run, then drag & drop files or folders onto it for processing.

KeyQuencer also has an eclectic miscellany of commands, such as: force a window or screen refresh; take a screen shot of a window or region; launch or close your PPP connection; get file info; dramatically show the cursor's position; relocate the frontmost window; drive an audio CD; alter the contents of the clipboard; manipulate ten clipboards; and read and write between the clipboard and a file.

Minor Annoyances -- These are things I noticed in passing, which probably shouldn't affect one's overall judgment of KeyQuencer. A few commands may not work perfectly: the sound-volume commands had no effect on my computer; the "scroll top/bottom" commands don't work in Nisus Writer. Some keystroke-combination triggers (such as the one that toggles KeyQuencer on and off) are not user-configurable. On my computer, Now SuperBoomerang sometimes didn't work within the Editor, and opening a suitcase sometimes writes garbage in the Online Help window and crashes. Within the Launcher, you can't configure the sort order in which the lists appear (by name versus by keystroke); you're stuck with the sort order you were using in the Editor the last time you saved. The syntax of the HyperCard XCMDs is not documented, and, finally, the manual could use more clarity of explanation and design.

Slouch To Judgment -- Here I'm supposed to sum up and tell you whether this is the macro utility you've been waiting for all your life. Truthfully, I just don't know. Though this is one heck of a program, I suspect it's not everyone's cup of tea; a great deal depends upon your mindset, your priorities, and your present repertoire of tools. Your best bet is to download the demo version that is supposed to appear soon on Binary's Web site and see how you like it. Meanwhile, some provocative reflections.

For sheer functionality, there's probably little QuicKeys can do that KeyQuencer can't somehow be made to do, and KeyQuencer has some abilities that QuicKeys lacks. Still, to some, the language might feel too daunting, or not fully-featured. My personal macro Holy Grail is to be given tools to build tools, and my mind runs along a one-program-one-function organizational track; so to me, KeyQuencer feels like a miscellany of extensions bundled together by an intractable language. I prefer OneClick's fuller programming and informational constructs that permit me to build my own multiple clipboards (vs. KeyQuencer's Clipboard command), to drive AppleScript to open or close MacPPP (vs. KeyQuencer's PPPSwitch), to obtain a list of windows and close all but the front one (which, as far as I can tell, KeyQuencer can't do at all). Also, since no one program does everything I want, I don't mind calling upon a battery of scripting tools to help me - Frontier, AppleScript, HyperCard, and so on. Possibly I'm just weird. I suspect your own feelings about these philosophical questions will be more decisive than feature issues such as KeyQuencer's lack of application-specific macros and recordability. For those who like a collection of ready-built high-level tools, KeyQuencer should prove attractive.

Most important, KeyQuencer operates to a high rigorous standard, something that not every macro program does. In the case of something so simple as a keystroke that scrolls the active window up one line, OneClick can't cope with Nisus Writer's windows because the scroll bar's up-arrow isn't in the normal location, but KeyQuencer "tells" the window to scroll in some deeper way and has no problem. KeyQuencer can simulate double-control-clicking on a window's title bar, which on my system activates WindowShade; I can't get OneClick to do that. This testifies to the dedication, the know-how, and the philosophical outlook of KeyQuencer's author, Alessandro Levi Montalcini. It's wonderful that such clean, powerful functionality can emanate from one person's brain in this day and age of megalithic software development corporations.

Another Deal -- We've also worked out a deal for TidBITS readers who wish to purchase KeyQuencer from Cyberian Outpost. If you use the specific URL below, you can order KeyQuencer 2.0 online and receive a $4 discount (think of it as free shipping).

<http://www.tidbits.com/products/key- quencer.html>

[Those of you hoping to compare KeyQuencer, OneClick (TidBITS-350), and QuicKeys (TidBITS-348) should stay tuned for a future issue. -Adam]

Binary Software, Inc. -- 310/449-1481 -- 310/449-1473 (fax)
<binary@binarysoft.com>

Article 6 of 9 in series

09 Aug 1999 | Print

QuicKeys 4 Presses My Buttons

by Matt Neuburg

Hide full article

Back in 1988, when Microsoft Word couldn't search and replace styles, a Classics student of mine named Adam Engst (what ever became of him?) put me wise to a solution involving macro automation, using CE Software's QuicKeys. QuicKeys could simulate user actions, such as clicking a button or choosing a menu item; each such action is called a shortcut. And it could string shortcuts together into little programs called sequences. You could trigger a shortcut or a sequence by pressing a combination of keys or by choosing from a special QuicKeys menu. With QuicKeys, you could automate, or provide keystroke-based access to, all sorts of common or repetitive tasks.

QuicKeys immediately became indispensable on my computer, but shortly after reviewing version 3.5 in 1996, I stopped using it (see the "Mac Macros" series of articles beginning in TidBITS-347). The Finder, and other programs I commonly use, were becoming more scriptable through AppleScript or Frontier; QuicKeys was having trouble with newer systems; and OneClick provided more programmable access to a greater range of functionalities.

<http://db.tidbits.com/series/1044>

Now QuicKeys is back, with version 4. What's new? Not much, really. CE Software added some new ways to create shortcuts: in the Finder, Control-click a file or folder, or drag it into a QuicKeys toolbar, to create a shortcut that opens it. Two types of shortcuts, when expressed as buttons on a QuicKeys toolbar, can now accept drag & drop of files and folders. There are some new shortcut abilities, such as locking a file, or changing Finder views. But what's really important is that QuicKeys now works with recent versions of the Mac OS.

<http://www.cesoft.com/quickeys/qkhome.html>

Macro My Mac -- Installation is greatly simplified, without so many pieces spread out over so many folders, and with only one extension required (the QuicKeys control panel). However, if you're upgrading, the time-consuming and confusing task of cleaning up from previous versions is left to you.

It's a pleasure to have QuicKeys back on my machine, and to greet old shortcuts as old friends. I'd forgotten how accustomed I was to typing a certain command to hide the current application, or to bring the Finder to the front. I restored custom keyboard shortcuts for menu items that lack them, or whose real shortcuts I dislike. On my PowerBook, which lacks an extended keyboard, I immediately restored ways of typing Home, End, Page Up, Page Down, and so forth.

While testing, I removed OneClick; and this reminded me that QuicKeys's abilities, though splendid, are fairly narrow. I have OneClick buttons that cascade my window positions, or present a list of windows so I can bring one to the front, or remember recently used applications and let me launch one from a list. QuicKeys's inability to do those things made me feel initially hamstrung.

Still, QuicKeys quite adequately handles most of my habitual needs. It can cycle through windows in an application. It can collapse or expand the frontmost window. It lets me maintain a palette of commonly needed folders; using the palette, I can open a folder, or copy a file into it. And some of what QuicKeys can't do can be accomplished by other utilities: it can't keep a list of recent applications, but Apple Menu Options can; it can't present a pop-up hierarchy of my hard disks, but The Tilery can; it can't present a list of open windows, but TitlePop can.

<http://www2.semicolon.com/Rick/Tilery.html>
<http://www.datavasara.fi/titlepop/>

On the other hand, QuicKeys is not a full-fledged scripting language (with variables and arithmetic and strings and the like), and generally can't perform actions that require one. For example, I commonly ask OneClick to collapse all but the frontmost window of the current application; QuicKeys is incapable of that, because it can't count the windows or cycle through them. QuicKeys can rename files according to certain preset templates, such as appending a serial number, but not in accordance with criteria that you create. QuicKeys can switch your TCP/IP configuration to one you've specified beforehand, but it can't present a list of your configurations and let you switch to one - even though it can do just that with your running applications. In short, QuicKeys's abilities are all highly specific and compartmentalized; it has no mechanism for generalizing them.

From another point of view, though, this limitation is an asset. QuicKeys isn't a scripting language because it doesn't want to be one. Many people are frightened by scripting languages: they can't program, or they think they can't, or they can't be bothered to learn. So QuicKeys lets you create shortcuts and sequences through familiar interface features such as lists and menus and dialog boxes that present simple sets of predetermined options. It may not permit customization to the degree that a scripting language does, but there's comfort in its confinement and clarity.

Ossify My Interface -- One of the big troubles is that QuicKeys's interface is far from clear. Its dialog boxes are rigid in infuriating, unnecessary ways. For example, you can't give certain shortcuts a descriptive title; a shortcut that chooses a menu item automatically has a title which is the same as the text of the menu item. And for certain shortcuts where you can assign a title, the title is limited to 15 characters. The result is that, viewing your list of shortcuts by their tiny or predetermined titles, you don't know what they do.

The native capabilities of certain shortcuts are so limited as to render them almost unusable. For example, ScrapEase lets you maintain multiple clipboards: you trigger a ScrapEase shortcut to copy selected text, which you then name in a dialog; then later you can trigger another ScrapEase shortcut to let you paste whatever scrap you choose from a list. But you can't easily delete a scrap: you must open the QuicKeys editor, find any ScrapEase shortcut, open it for editing in a dialog, press a button to bring up another dialog listing your scraps, select one and press Delete, confirm the deletion in yet another dialog, and then dismiss the whole nest of dialogs one by one. The result is a reluctance to use this feature, because management is so inconvenient.

Creating a shortcut requires navigating a mysterious nest of hierarchical menu items. Consider the following actions: collapse a window; switch to the rear window; switch to the next application. Who would ever have guessed that these are accessed, respectively, through System Tools -> Mousies, System Tools -> Specials, and System Tools -> MacOS [sic] Specials? And each of these choices just brings up a dialog; you must still find the desired function in yet another menu. So even if you know that a certain shortcut type exists, you don't know where to find it; either you spend all your time guessing, trying different menus and dialogs, or you look in the manual.

CE has done nothing to resolve the problems engendered by dependencies of one shortcut on another. Such dependencies can make understanding your shortcuts difficult, and editing them hazardous. For example, in a sequence you can include a Decision shortcut, which is the QuicKeys version of an "if" statement: if a certain situation is the case, QuicKeys triggers a certain other shortcut. But this other shortcut must exist separately. So when you examine your Decision shortcut, in a modal dialog, you don't know what it does, because it calls another shortcut, which you can't examine because you're in a modal dialog. Conversely, when you look at the list of your shortcuts, you see that other shortcut, with no understanding of why it exists: there's no indication that it is called by a separate Decision shortcut. So you might easily delete it, thereby rendering your Decision shortcut powerless; or, more likely, you're afraid to delete anything, because you have no way of knowing what dependencies you might destroy. In effect, as soon as you have shortcuts or sequences of even the slightest complexity, they become unmanageable.

The same is true of toolbars. To include a shortcut on a toolbar, the shortcut must exist separately. But when you're looking at the list of your shortcuts, nothing tells you that a shortcut is associated with a toolbar, so you can easily delete it, thereby accidentally removing its button from the toolbar. Conversely, when you're editing a toolbar, you're shown a list of your toolbars and a list of your shortcuts, but you're not shown any association between the two. And if you're editing a toolbar, what's one of the main things you'd probably like to do? Edit one of its shortcuts, of course. But you can't; shortcut editing and toolbar editing happen on two different tab panels.

It appalls me that CE has given no attention to these and similar problems. Far from taking the opportunity of this revision to address such long-standing issues, they've maintained an arcane and archaic interface that dates back twelve years, merely dressing it up with some colors and Appearance Manager-compliant buttons.

Shoot Myself in the Foot -- None of the above means that I don't like QuicKeys 4. I love it! It's stable, it's fast, it's reliable, it doesn't seem to slow or interfere with my Mac's operation. And it has always had these interface problems, so I'm used to them. But I'm disappointed with CE Software for not fixing them, especially since I've been writing about them in TidBITS for years. Of course, this is the company that acquired WebArranger, one of the coolest programs in history, then failed to understand it, failed to support it, and eventually discontinued it. CE Software has no record of following my advice. But if this is the best that CE can offer its customers who have waited patiently for three years, it's a bad sign. And why would such a clumsy interface attract new users?

<http://db.tidbits.com/article/01149>

The QuicKeys manual is poor. Too much of it is devoted to self-promotion; phrases like "time-saving" and "work more efficiently" appear frequently, as if the reader needed constant reminding why the program was purchased in the first place. Far too little of it is devoted to teaching and explaining. There are many errors. It's also badly laid out, with fonts that don't harmonize, and a short, wide two-column format that makes the PDF version illegible on most any monitor.

In one respect, though, CE improved the manual. QuicKeys Script, CE's OSA-compliant scripting language for driving QuicKeys from other programs, is no longer hidden away from view; it is described in the manual, and in place of syntax specifications using arcane mathematics-like symbols, there are now easy-to-read tables.

I've explained, in an earlier essay, why you need a macro program. And once upon a time, QuicKeys was the only game in town; so you needed QuicKeys. But no longer. There's OneClick. There's KeyQuencer. There's PreFab Player. Plus, the Mac OS itself is more scriptable than it used to be, through AppleScript or Frontier. With QuicKeys 4, CE Software has failed to acknowledge this competition; so far from taking renewed responsibility for the care and feeding of this fine, classic program, they've left it with a poor interface, a muddy manual, and limited capabilities. The result is that users have few reasons to choose QuicKeys over the younger and hungrier competition. That's sad.

<http://db.tidbits.com/article/00801>

QuicKeys retails for $100; competitive upgrades are $50. A 2.3 MB 30-day demo version is available for download.

<http://www.cesoft.com/quickeys/ qkmac40demo.sea.hqx>

Article 7 of 9 in series

03 Apr 2000 | Print

Freedom of the Button Press - OneClick 2.0

by Matt Neuburg

Hide full article

In the struggle to return control of the computer to the user, macro utilities are indispensable. Such a utility acts as a ghostly simulacrum of a live user, choosing from menus, typing keys, and clicking the mouse; an assemblage of such actions can essentially script the unscriptable, driving any application to customize or automate frequent or repetitive tasks. From my earliest days with the Macintosh, QuicKeys was my constant companion; I've also looked at KeyQuencer. But if I had to use just one macro utility, forsaking all others, my choice, despite its faults, would be OneClick, from WestCode Software.

<http://db.tidbits.com/series/1044>
<http://www.westcodesoft.com/>

Refined Palettes -- OneClick creates floating windows (palettes), each of which can be either global or associated with a specific application. A palette contains buttons; every button has a script, a sequence of actions which you create and edit as text in an easy programming language appropriately named EasyScript. A script can contain various subroutines, called handlers. Handlers are the code that actually gets triggered, and in forming a mental picture of OneClick, it helps to know how this occurs. (Bear in mind that an application-specific palette cannot be visible, nor can its scripts run, unless the application is frontmost.) Here are the triggers:

You click and release the button. This triggers the button's MouseUp handler.
You click the button and hold down. This triggers the button's MouseDown handler. Such a handler can construct a menu and make it pop up from the button, and then proceed in response to the user's menu choice. Since pop-up menus require that the mouse button be down, this would make no sense in a MouseUp handler. If a button has both a MouseDown handler and a MouseUp handler, the latter will never be automatically triggered; they are mutually exclusive.
You type the button's keyboard shortcut. This triggers the button's MouseDown handler if there is one, otherwise its MouseUp handler. A palette does not have to be visible for its keyboard shortcut to work, and buttons on palettes belonging to different applications can use the same keyboard shortcut. Thus, OneClick actions can be triggered purely from the keyboard, as with QuicKeys; this should satisfy those who, like several members of the TidBITS staff, dislike most palettes.
You drop something on the button. This triggers the button's DragAndDrop handler. You can drag text (from an application that can initiate true text drag & drop), or Finder items; the script receives the text or the pathnames, respectively, and can respond as desired.
Something causes the button to be redrawn - for example, the palette becomes visible, or the button changes its appearance through being pressed by the user or commanded by a script. This triggers the button's DrawButton handler.
The palette's associated application (or, for a global palette, the computer) starts up. This triggers the button's Startup handler. For example, if a badly behaved application requires a click from the user to dismiss its opening splash screen, OneClick can perform the click.
A certain time period elapses, or a system event occurs. This triggers the button's Scheduled handler. You configure what time period(s) or event(s) will act as triggers, which you typically do in the Startup handler. Common events to which OneClick can respond are: an application starts up or quits, a new window comes to the front, or a OneClick palette is shown or hidden. Suppose you wanted a certain palette to appear in response to the mouse moving over a "hot spot" such as the lower left corner of the monitor. You could configure a Scheduled handler to be called every second, polling the mouse's position and showing the palette if the mouse is at the hot spot.
Another handler calls the one in question by name. The calling handler need not be in the same button, nor even in the same palette. In fact, a handler can be called from an AppleScript running anywhere; thus, HyperCard or QuicKeys or even Microsoft Word could trigger a OneClick script.

Clearly there is great power and flexibility in this capacity of button scripts to be triggered in so many different ways. And OneClick's buttons are also customizable: they can contain text or icons, they can be drawn in various ways, in any size or color, and so forth. Thus, a OneClick palette can be made to look just right for its application. Nonetheless, it isn't its system of buttons and palettes which makes OneClick the place I'd prefer to be when writing a macro script - it's the nature of the scripts themselves.

It's the Scriptability, Stupid -- OneClick scripts are text, written in a real programming language with real programming features such as variables, looping and branching constructs, arithmetic calculation and string manipulation, and even a pleasant object-based syntax. And OneClick provides oodles of built-in functions for letting this language do powerful things.

Naturally, you can perform all the ghostly user-like actions you'd expect from a macro utility. You can click the mouse at given coordinates, possibly with modifier keys or dragging. You can type. You can examine menu items, and choose one. You can inspect a button's state, and push it. You can select, scroll, resize, reposition, zoom, or collapse a window; you can even read its text.

You can perform various system- and Finder-level activities. You can manipulate the clipboard; show, hide, and reorder running processes; obtain screen resolutions, sizes, and positions; create, copy, open, and delete files and folders; read or change a file's text or Finder information; and mount or obtain information about a volume.

You can interact with the user. You can put up a dialog, give it customized buttons, let the user type some text into it, let the user choose an item from a list, and show the standard File Open or Save dialog or even the Color Picker dialog. You can supply help text that will appear when the user holds Shift-Option with the mouse over a button. You can change the cursor. You can play sounds, or have the Speech Manager speak some text. You can poll the mouse button or the keyboard; so, by learning what modifiers the user is holding, you can give a button multiple functionalities. You can allow a button to receive something using drag & drop; you can also permit text to be dragged from a button. You can cause various sorts of pop-up menu to appear for the user to choose from: a menu that you construct from scratch, a hierarchical menu of files and folders on disk, a menu showing all the characters of any font, or even an entire palette behaving like a pop-up menu.

You can run an AppleScript script, thus scripting the scriptable as well as the unscriptable. This can be a compiled script file created in Apple's Script Editor, but in most cases it can simply appear inline within a button script.

Finally, everything about OneClick's own buttons and palettes can be controlled from scripts. You can change a button's text or appearance, make a button display a thermometer or pie-chart as feedback, dictate conditions under which the user can reposition a button or palette by dragging, even create a palette and populate it with buttons "on the fly." Thus, palettes themselves become powerful interface tools, where the buttons combine to form some complex live functionality, such as a calendar.

With such power and flexibility, it's little wonder that OneClick is put to a great variety of ingenious uses - some sense of which may be gleaned from WestCode's page of user-contributed palettes. In fact, WestCode sells a number of its own palettes extracted from the full OneClick distribution separately, along with a runtime version of the OneClick engine.

<http://www.westcodesoft.com/FTP-Buttons.html>

Compared to this, my own use of OneClick is rather tame, mostly because I'm conservative about using buttons scripted by others. Still, a survey of my own habits yields a taste of OneClick's possibilities. On my computer are palettes, buttons, and keyboard shortcuts that do the following.

Show the font, size, and styles of the currently selected text in Nisus Writer (because otherwise you have to peep into half a dozen different menus to learn this information).
Position and size the frontmost Acrobat Reader window nicely, and to zoom it to Fit Width.
Fix capitalization and remove extra spaces in clipboard text (to make up for ViaVoice's mistakes).
Connect to or disconnect from the Internet, by driving the Remote Access control panel.
Implement multiple simultaneous clipboards.
Toggle the collapsed setting of the frontmost window or of all other windows.
Interfere with the Help key, which I often strike accidentally.
Supply PageUp, PageDown, Home, End, Forward Delete, and Help keys, which are missing from my PowerBook.
Hide the frontmost application or all others, or bring the Finder to the front.
Use the pathname on the clipboard to open a file or folder.
Speak the selected text.
Toggle the visibility of the Application Switcher.
Choose among my various TCP/IP configurations.

Plus, I use some buttons supplied by WestCode to manage text clippings, change speaker volume, open various system folders, manipulate windows and processes, and navigate the Finder hierarchy. Much of the above are functionalities I was previously achieving in some other way; OneClick all by itself makes many other extensions and utilities superfluous.

Yet though I love OneClick and wouldn't want to be without it, using it can be unpleasant and risky. Next topic: the downsides of OneClick.

Cold Shower -- The script editing environment, despite its nice online help and compile-time syntax checking, is crude. OneClick lacks a Find command, a built-in debugger, and notification of runtime errors. So OneClick becomes what I call "guessware": constructing, debugging, or just understanding a script can range from painful to well-nigh impossible. One can develop workaround tools and techniques, but one shouldn't have to, and besides, this will be hardest for the beginners who most need them. The trouble is compounded by hidden traps in the EasyScript language; for example, "for x = 1 to n" will execute its loop even if n is zero, and complex nested function evaluations often don't work - you have to evaluate all the pieces as separate variables first.

If you're not prepared to crash now and then, or for things to go mysteriously wrong, OneClick isn't for you. At various times, such as when I was writing my first book, I had to stop using OneClick altogether, because I couldn't afford such frequent crashes and corrupted data. Even in just the few days writing this review, I crashed trying to open a script for editing, again trying to save a script, and again trying to import a saved button; numerous attempts to load a saved palette failed without notification. Users have reported finding scripts replaced with nonsense, or unaccountable automated actions suddenly taking over their computer; in the past few days I myself have seen weird unsummoned windows flash on the screen, Finder items spontaneously duplicated, and other unexplained phenomena. Palette corruption is a constant danger. Some of these problems may relate to Scheduled handlers: when they fire, they give no indication of what is happening; they can interrupt one another; and there is no way to learn what schedules are pending. This is one reason I am chary of buttons I didn't write myself.

Even OneClick's most basic level of functionality, which presumably involves interfering with the user's mouse-clicks and generating its own to press buttons and choose menu items, is not completely reliable. Sometimes OneClick is just unaccountably slow: I've seen it take well over a second to bring a window to the front in Acrobat Reader; in REALbasic, buttons can be so unresponsive as to be useless; in DiskTop, it's far worse. In Eudora, activating a window through OneClick sometimes activates the wrong one. I've seen arithmetically calculated values occasionally come out the negative of what they should have been. Users report that typing in the script editor window sometimes "falls through" to the application behind.

Nor does WestCode Software's record of commitment to the survival and support of its product inspire confidence. In late 1996, WestCode cautioned me not to review OneClick 1.03, because 1.5 was about to appear; the next actual upgrade turned out to be 2.0, three years later. The 2.0 beta development process was heartening, but progress was glacial, and WestCode often seemed more inclined to fend off the bug reports than to fix the bugs. Many glitches have been left in this release: there is script window corruption when you make a syntax error, keyboard shortcuts involving "a" don't work, and despite claims of Mac OS 9 compatibility, OneClick doesn't work properly with some Appearance Manager or Navigation Services dialogs. Potential users must judge for themselves whether this sort of laxity is venial or suggestive of possible deeper trouble.

The manuals are quite good, but rather out of synch with how OneClick actually works; for example, installation doesn't work the way the manual describes it, some screen shots don't match reality, some documented features (such as the ability of control strip modules to be OneClick buttons) don't actually work, and some important and potentially confusing features, such as the ability to "lock" a button (so that it can be pressed while you're editing a script), are completely undocumented. Also, there are two manuals, one for EasyScript, one for everything else, because WestCode wants to convey that OneClick can be useful even if you don't do any of your own scripting; and some 70 pages of material is repeated in both, which is cumbersome and confusing.

Bottom Line -- For me, OneClick's scriptability, power, flexibility, and downright usefulness outweigh all the negatives I've outlined; and the price is extremely competitive. I do wish that OneClick worked a bit more cleanly, and that I felt more encouraged about its future. Nonetheless, whether you want to take advantage of the many powerful palettes available online, want to clean up and rationalize your computer's interface, or want to tinker, customize, and automate with code of your own, OneClick is a superb macro program with a wonderful interface that deserves your serious consideration.

OneClick typically occupies less than 500K of RAM, and is about a 7 MB installation. OneClick costs $60 for the downloadable version with two PDF manuals, or $80 on CD with one printed manual; the printed scripting manual is $20 more. OneClick requires System 7 and a 68020 processor or later.

Article 8 of 9 in series

22 Oct 2001 | Print

QuicKeys X: The Return of the Ghost

by Matt Neuburg

Hide full article

With the advent of Mac OS X 10.1, I'm using Mac OS X nearly all the time, but many of my long-standing work habits have become useless. That's because those habits rely on third-party utilities that haven't made the transition - and, one fears, may never do so. In Mac OS X, after all, the system works in a whole new way, and developers must learn entirely different methods to hack into it and modify its functionality. Still, it's far from clear what the limits ultimately will be, and we should never underestimate the ingenuity of Macintosh developers.

Even as Mac OS X first shipped, I was wondering what in particular would become of macro utilities, those "ghosts in the machine" that perform preset actions by fooling your computer into thinking that an actual user is typing keys and wielding the mouse. So it's with some joy and relief that I find that CE Software's QuicKeys has followed me down the rabbit-hole and into the garden of Wonderland - but alas, only, like Alice, by drinking from the bottle that makes you smaller.

<http://www.cesoft.com/products/qkx.html>
<http://db.tidbits.com/series/1044>

In Mac OS X, QuicKeys X is an ordinary application that must be running for you to trigger any shortcuts, so you'll probably make it a startup item by way of the Login preferences panel. Being an ordinary application, QuicKeys X now has ordinary windows and menus, which means that its interface is much improved. Gone are the impenetrable layers of modal dialogs. Indeed, CE has made QuicKeys's windows wonderfully Mac OS X-like, with splendid use of drawers, customizable toolbars, and drag & drop. It's so easy and intuitive that you probably won't even have to read the manual. However, there's still no straightforward list of all your triggers, and there's no way to learn what sequences or floating palettes an action is used in; these are problems I've pointed out for years, and it would have been nice to see CE take this opportunity to tackle them.

<http://db.tidbits.com/series/1044>

A QuicKeys action can have various triggers, and these can be universal or confined to a particular application being frontmost. The possible triggers for an action are: a keyboard combination or sequence of keyboard combinations; an absolute time, a time interval after startup, or a repeated time interval; clicking in a QuicKeys floating palette; or choosing from the QuicKeys menu (at the right end of the menu bar or in the Dock).

The narrow range of available actions suggests the limitations imposed upon QuicKeys by Mac OS X. QuicKeys X can type; it can move and click the mouse; it can sleep and shut down the computer; it can send a command to the Unix shell. These are invaluable. The remaining things that QuicKeys can do are achievable in other ways, and are notably less interesting, though welcome for enhancing sequences of actions. QuicKeys can open a file or folder, run an AppleScript script, switch among applications, open a URL, change the Finder's view of a folder, and switch between folders in an Open or Save dialog.

But QuicKeys can no longer click buttons or choose menu items by name, switch or scroll windows, access the clipboard, or send a raw Apple event. Also, QuicKeys X is now unable to "see" the screen, so it can't make decisions based on a certain window being frontmost or a certain menu item being enabled. QuicKeys's scriptability is also greatly curtailed; basically, it can run an action that you've previously created and named, and that's all.

QuicKeys X is a welcome and pleasant release, and I'm already putting it to good use. I've stocked it with some boilerplate phrases to be typed into any application, and I've made certain menu items accessible through keyboard shortcuts (though these are slow and unreliable, because instead of choosing the menu item directly, QuicKeys must move the cursor to the item's location). But QuicKeys is only a part of my bag of tricks.

I don't wish to sound overly negative about QuicKeys X - it may not yet measure up to the full capabilities it provided under Mac OS 9, but it is essentially a 1.0 release because everything it knew how to do in the past has changed with Mac OS X. Just as it's taking us all some time to learn new ways of interacting with Mac OS X as users, so too it's taking time for Apple to expose the innards of Mac OS X to the depth necessary for CE's engineers to write a tool as downright magical as a macro utility. CE has said they will be extending QuicKeys X's capabilities in the future; we wish them luck in ferreting out the secrets to automating Mac OS X's internal workings.

CE will have to move quickly, since a number of small utilities are coming out for Mac OS X that replicate some of QuicKeys's features. Typing text into applications can be handled by Selznick Scientific Software's Typist or Michael Kamprath's Keyboard Maestro; programs like DragThing, LaunchBar and Sig Software's Drop Drawers offer ways of opening and switching between applications, and launching AppleScript scripts; and I'm sure utilities I haven't yet run across are nibbling at other QuicKeys features.

<http://www.selznick.com/products/typist/>
<http://www.keyboardmaestro.com/>
<http://www.obdev.at/products/launchbar/>
<http://www.dragthing.com/>
<http://www.sigsoftware.com/dropdrawers/>

QuicKeys X costs $60, and a 30-day demo version is available for download.

Article 9 of 9 in series

10 Mar 2003 | Print

Scripting the Unscriptable in Mac OS X

by Matt Neuburg

This is the tale of a U.S. government statute, a certain Cupertino-based computer company, and a small revolution taking place quietly on your computer, if you use Mac OS X 10.2 Jaguar. To understand this revolution, you need to know what a macro program isShow full article

Hide full article

This is the tale of a U.S. government statute, a certain Cupertino-based computer company, and a small revolution taking place quietly on your computer, if you use Mac OS X 10.2 Jaguar.

To understand this revolution, you need to know what a macro program is. I've been writing in TidBITS about such programs for years. Simply put, there are certain frequent or repetitive computer tasks that one would like to be able to automate. This is often straightforward if the program that performs these tasks is scriptable, meaning that it responds to a repertory of AppleScript commands: you just write a script expressing what you want done. But what if the program is not scriptable?

Of Macs and Macros, Take Two -- One solution that worked pretty well for me in previous incarnations of the Mac OS was to use a macro program. Such a program must hack into the Mac OS itself so as to be able to simulate the presence of a "ghost" user who can press keys and move and click the mouse just as a real user would. By stringing together such actions, the computer could sometimes be forced to make up for the lack of scriptability in certain applications. Macro programs that I formerly used include PreFab Player, QuicKeys, OneClick, and KeyQuencer.

<http://db.tidbits.com/article/00801>
<http://db.tidbits.com/series/1044>

Now wind the clock forward to Mac OS X. The trouble here is the word "hack" in the previous paragraph. One of the main points of Mac OS X is that you can't hack the operating system; to preserve stability, Apple has abolished the kind of extensions that used to make such hacks possible. Unfortunately, this means that macro programs don't work all that well on Mac OS X. When QuicKeys was migrated to Mac OS X, I was appalled how poorly it worked. It had trouble performing certain kinds of actions, such as choosing from menus and pushing buttons; and, more important, it couldn't "see" what menu items and buttons were present, so it couldn't make intelligent decisions or wait for the right window to appear.

<http://db.tidbits.com/article/06603>

These limitations, of course, were not the fault of QuicKeys. Since QuicKeys couldn't hack into Mac OS X, it could see and act only in ways permitted to it by the various legitimate application programming interfaces (APIs) provided by Apple. And Apple, concerned with stability, wasn't about to let just any old program reach in and start meddling with some other program's windows and menus. Knowing this, however, did not solve the problem; and users were left staring at QuicKeys, waiting for it to improve. It did; but not much.

<http://db.tidbits.com/article/07022>
<http://db.tidbits.com/article/06786>

Now for the revolution. While we were all staring the wrong way - at QuicKeys - the problem was being solved by Apple itself. And the solution (in general, and for future versions of QuicKeys as well) is in place, right now. You can script unscriptable applications, manipulating their menus and windows and buttons, and typing text, right now. It's just that Apple hasn't bothered to say much about it, so few people know.

Enter Uncle Sam -- How could this happen? And why did it happen? It all goes back to a U.S. statute called the Workforce Investment Act of 1998, commonly known as Section 508. This statute says that when federal agencies procure electronic information technology, that technology must give disabled people access to information that's comparable to the access it gives non-disabled people. In plain English, if you manufacture computers, and you want any government agency to be able to buy any of them, they must be fully operable by people with disabilities.

<http://www.usdoj.gov/crt/508/508law.html>

To see what this statute might mean for Apple Computer, Inc., let's put ourselves inside the mind of someone at Apple Computer, Inc. This person is imagining a Mac being operated by someone with a disability. And he or she is thinking: "Suppose this disability is such that the user can't work with the keyboard or the mouse. Holy cow! Unless we want our government sales to be zero, we'd better provide a way, in Mac OS X, for some other device, such as one of those sip-and-puff joysticks, to be able to operate all parts of the user interface." Clearly such operation implies something far beyond merely a few keyboard shortcuts that substitute for the mouse some of the time, as in the Universal Access and Keyboard preferences panes. It means that the system itself must be able to "see" and access all the individual interface elements of any application, so as to provide a pathway whereby a joystick, or any other assistive device, can press every button and click in every text box and somehow reach every interface element that appears on the screen.

<http://www.apple.com/macosx/jaguar/ universalaccess.html>
<http://www.abilityhub.com/mouse/joystick.htm>

The idea, then, is this. Given any application on Mac OS X, it needs to be possible for some other application to discover what interface elements it is displaying. The other application needs to be able to "read" these elements ("There's a button that says OK") and it needs to be able to access them (click the OK button). Apple went to work on the problem, and the result, which first emerged to public view in Jaguar, is the Accessibility API. Actually, there are two things going on. Under the surface, Apple has provided some deep magic, in the operating system itself, that does the reading and the accessing of all the interface elements present on the screen. Closer to the surface, Apple has provided the API, which is a set of commands a programmer can use to take advantage of this magic.

<http://developer.apple.com/techpubs/macosx/ Cocoa/TasksAndConcepts/ProgrammingTopics /Accessibility/>
<http://developer.apple.com/techpubs/macosx/ Carbon/HumanInterfaceToolbox/ Accessibility/MakingAppsAccessible/>

Now stop and think about what I just said. This is all present in Jaguar, right now. So anyone can write a program that can see and access the interface elements of any other program, right now. But such a program would, in effect, be a macro program! In short, the various things QuicKeys couldn't do when it first appeared on Mac OS X, because it couldn't hack into the Mac OS, any program can now do, thanks to the Accessibility API.

But it gets better. Read on.

Blessed (System) Events -- At some point, someone at Apple put two and two together, as follows. "On the one hand, we've got the Accessibility API, which lets any program access the interface elements of any other program. On the other hand, we've got AppleScript, which lets any user write a script to give commands to any scriptable program. So what would happen if we put them together? Any user would be able to write a script to give commands to a scriptable program which would use the Accessibility API to access the interface elements of any program." To see the significance of this, just take out the middle terms, and what have you got? Any user can write a script that can access the interface elements of any program. Any user can script an unscriptable program, using AppleScript! You wouldn't need any special macro program, because AppleScript itself, which is already on your computer, would become a macro language.

Of course, for this to work, there has to be that "middle term" - the go-between, the application that receives AppleScript commands and talks to the Accessibility API. That application is called System Events. It's on your computer right now, in /System/Library/Core Services. But the version of System Events that knows about the Accessibility API is probably not on your computer, because it's in beta and is not part of the standard Mac OS X release. You must download and install it separately, from Apple's GUI Scripting Web page.

<http://www.apple.com/applescript/GUI/>

Let's try it out! There are two preliminary steps.

Download and install the beta version of System Events.
In the Universal Access preferences pane, check the box at the bottom that says "Enable access for assistive devices." This is crucial because it throws the virtual switch that brings the Accessibility API into play.

We'll also need an unscriptable application to operate on. For this example, we'll use my own freeware MemoryStick, so download it (and shame on you) if you haven't got it.

<http://pages.sbcglobal.net/mattneub/downloads/ MemoryStick%20Installer.dmg.gz>

MemoryStick isn't scriptable, and was never intended to be. Nevertheless, as if by magic, we're going to open its Preferences window, find the Poll tab item, read how often MemoryStick is set to poll the system, and click the spinner up or down the right number of times so that the setting ends up at "5 seconds" - and then close the Preferences window. Ready?

Start up MemoryStick if it isn't running. Start up Script Editor (it's in /Applications/AppleScript). Paste in the following script:

tell application "MemoryStick" to activate
tell application "System Events"
  tell application process "MemoryStick"
    click menu item "Preferences..." of menu "MemoryStick" of menu bar 1
    tell tab group 1 of window "MemoryStick Preferences"
      click radio button "Poll"
      get value of static text 3
      copy the result as number to theVal
      set theDec to theVal - 5
      if theDec > 0 then
        repeat theDec times
          decrement incrementor 1
        end repeat
      else if theDec < 0 then
        set theDec to 0 - theDec
        repeat theDec times
          increment incrementor 1
        end repeat
      end if
    end tell
    click button "Done" of window "MemoryStick Preferences"
  end tell
end tell

Now run the script, and watch the fun. Don't blink, or you'll miss it!

Future Directions -- By now, you're probably saying, "Wow! That was great! How can I learn to give these sorts of commands to any application, so that I can script unscriptable applications and turn AppleScript into a macro programming language?"

Luckily, there's a splendid way to do this. It's called PreFab UI Browser, the work of Scott Lawton of PreFab Software, who brought us PreFab Player and TextMachine, and Bill Cheeseman, the well-known AppleScript guru and author of Cocoa Recipes for Mac OS X. This brilliant little program uses the Accessibility API to "look" at all the interface elements of any running application, and generates the AppleScript commands you'd use to click them, read them, type into them, or whatever. It's $25 (until mid-April, when the price goes up), and a 30-day demo is available.

<http://www.prefab.com/uibrowser/>
<http://db.tidbits.com/article/04198>
<http://www.applescriptsourcebook.com/>
<http://www.amazon.com/exec/obidos/ASIN/ 0201878011/tidbitselectro00>

It will be interesting to see what further applications will emerge that take advantage of the Accessibility API. For example, one of my favorite utilities in earlier days was an extension that listed all the windows in all running applications, so that you could switch directly to the right window, no matter what application you were in now. Before the Accessibility API, such a utility was impossible in Mac OS X, because no application could "see" another application's windows, let alone switch amongst them - the Dock could do it, but only because it belonged to Apple and was privy to System-level secrets no one else had. But now, writing such a utility should be easy.

The story is not over, not least because both the Accessibility API and the Scripting Events beta are still young, still in development, and still buggy. Nevertheless, they do work, as the example proves; and eventually, perhaps as part of the next major update to Mac OS X, I would expect the special version of System Events to come out of beta and be made part of the standard release. Meanwhile, now that you know the secret, you can start playing with AppleScript in its wonderful new role as a macro language on Mac OS X.

As you do, keep in mind that even the Accessibility API can't perform miracles; it can't detect interface items that are not constructed by way of Mac OS X's built-in toolbox. A program that uses non-standard interface items can be written deliberately to provide Accessibility API access to them; but if it isn't, the Accessibility API is blind. For example, the Accessibility API can't see any of Microsoft Word's menus, toolbars, or even the text of a document.

Not that this matters, of course, because Microsoft Word is completely scriptable already. Which raises another point: There's no substitute for true scriptability. To write an application of any serious power without giving it the ability to be driven with AppleScript is simply poor programming practice. So, if you're able to automate some previously unscriptable area of your workflow through Accessibility API scripting, that's splendid; but if the target program is still being actively developed, please do also write to the developers and ask that they make that same functionality genuinely scriptable.

PayBITS: If Matt's article makes a difference for what you
can script, consider sending him a few bucks via PayPal!
<https://www.paypal.com/xclick/ business=matt%40tidbits.com>
Read more about PayBITS: <http://www.tidbits.com/paybits/>

Show the full text of all articles

TidBITS Watchlist

Printing onto Forms from Preview

Recent TidBITS Talk Discussions

Series: Mac Macros

The User Over Your Shoulder - Of Macs and Macros

Form, Function, and QuicKeys 3.5, Part 1

Form, Function, and QuicKeys 3.5, Part 2

OneClick - A Super Utility

KeyQuencer - QuicKeys Quencher?

QuicKeys 4 Presses My Buttons

Freedom of the Button Press - OneClick 2.0

QuicKeys X: The Return of the Ghost

Scripting the Unscriptable in Mac OS X