Comments on: We Need a Hero Official blog of Red Sweater Software Wed, 14 Mar 2007 00:42:03 +0000 hourly 1 By: flight16 Wed, 14 Mar 2007 00:42:03 +0000 I just logged in at and as of 3-5-2007 they have a few new sample AppleScript apps with code, complete with detailed(?) readmes. I haven’t sat down with any yet, but they look promising… at least for an AppleScript newbie like me.

By: Mark Myers Thu, 25 Jan 2007 18:36:22 +0000 I “cut my teeth” in programming using AppleScript to automate prepress workflows for the newspaper industry, and have since added perl and am currently adding Cocoa/Obj-C to my toolset. While agreeing with the frustration levels many in this post have experienced in writing AppleScript, and understanding the headache it must be to add AS support to Cocoa applications (I have yet to cross that bridge), I see AppleScript as a continued necessity for good Mac apps. Why? Because it is an end-user, doesn’t-have-to-know-computer-programming, language for “the rest of us.” If I had not had AppleScript as a gentler learning curve into a broader world, I don’t think I would have bothered trying. And I know of many others whose experience was similar. The truth is, abstracting the complexity of controlling applications to the end-user level necessitates a language that doesn’t require a complete shift in syntax rules from what the average Joe already knows — i.e., English.

I do agree that AppleScript needs some work. Better list manipulation, a regular-expression syntax, stronger support in the finder, more recordability, and a LOT more speed are things that I would give my right arm for. As for standardization, I think much of the problem is the result of third-party developers not putting in the effort to compare their applications’ AS behavior with existing applications that have rich, intuitive scripting dictionaries. It would help if Apple did some work on standardizing and documenting the way dictionaries should be written, but in a somewhat obscure way standards do exist. Back when I started, QuarkXPress was considered a standard bearer in scriptability (although InDesign has far surpassed it), and there are many apps today (thanks, OmniGroup, Adobe, and others!) that other developers should be looking to in order to see ways most AppleScripters expect their precious language to be implemented. Perhaps we need an Indie AS Implementation guide similar to the Indie HIG.

I have two suggestions, from an end-user’s perspective, to developers when contemplating adding AppleScript support:

1) Expose as much of the functionality of your application as possible to the OSA engine. Please don’t leave needed functions “in the dark” from an AS point of view. A good bad example of this is the more recent iterations of QuarkXPress (I’m thinking of 6.5) where they added a wonderful PDF Export ability but did not make that function scriptable, forcing us AppleScripters to continue to rely on printing or exporting as EPS, and then passing the resulting file into Distiller. And anyone who has ever tried scripting QuarkXPress printing can attest that it is wildly unreliable at best.

2) Use terminology in your dictionary that mimics the same concepts reflected in the GUI. In other words, write your AppleScript syntax in such a way that if I understand how to do a particular process from the GUI, I can easily map that knowledge to the identical feature in AppleScript. This does not mean scripting button clicks and palette openings, but if I want to, say, create a 2″ by 2″ text box 1″ from the side of the page and 3/4″ from the top, I shouldn’t have to learn an obtuse reference form to do so. AppleScript implementation should be as elegant and well-thought-out as the GUI.

Lastly, I should note that I strongly disagree with posters suggesting this or that framework for adding support for specific scripting languages to applications. The LAST thing we need is for every developer to decide what scripting language their application is going to use and essentially isolate it from the rest of the scripted-application world. One of the most powerful features of the OSA is its ability to pass instructions from one application to the next. Most AppleScript workflows I and others have created use at LEAST two applications. Even if you prefer to use a different scripting language yourself, please take the time to implement the OSA in your app. This way, using an OSA component, anyone can write their scripts in whatever language they prefer. And us AppleScripters can continue on in our blissful, English-like world.

By: Steven Tue, 24 Oct 2006 00:25:22 +0000 Sal wrote:
Regarding Python: I’m curious, has anyone here tried the Python OSA component at:
Would that address your issues if it, or something similar, was included in the OS?
Yes!! Please!!!
I saw this statement and I jumped for joy.

Something like appscript and Pyobjc that you guys would fold into the os and mantain, not instead, but in addition to AS. That would provide the best of both worlds for everyone, AS for the novice and for those expert users with legacy needs and Python for those of us who prefer a more traditional programming aproach . But documentation and examples are paramount. How about getting that in 10.5 ?
Best regards,
Steven Quinones-Colon

By: nik Mon, 16 Oct 2006 15:10:53 +0000 And now there also is a Ruby/Apple-event bridge by Hamish Sanderson:

It’s already used by the safariwatir project, btw!

By: Brennan Young Sun, 15 Oct 2006 21:22:48 +0000 Very interesting discussion here. How wonderful to see Sal responding to it so positively.

I am a scripter rather than an ‘implementor’ but I have worked closely with various developers as they struggled to implement AppleScript in their apps. It has always been a world of pain.

Here are a few points I’d like to raise:

AppleScript implementation needs to be a ‘no-brainer’, and preferably something which happens ‘automagically’ in Xcode (at least for Cocoa apps).

Apple should lead the way with its own AppleScript implementations. There are a few good ones (e.g. QuickTime Player), some really bizarre ones (TextEdit) and plenty of quirky, abandoned monsters (e.g. AppleWorks).

Far too many important (and expensive) Apple apps (e.g. pro audio/video) have no AppleScript support at all. This is a very poor show. The pros that need this stuff as much as the amateurs!

Some of Apple’s own scriptable apps go directly against the design guidelines described in the famous TN2106. (e.g. iTunes). This should be fixed, even if it breaks older scripts. I think at least we should hear some good excuses for why the iTunes dictionary has both ‘updatePodcast’ and ‘updateAllPodcasts’. (And what’s with the ‘camel case’? What a howler!).

Applescript is deliberately designed as a ‘little’ language (i.e. it’s mostly just the core syntax, with the API provided by app developers), but there are a small handful of half-implemented ‘core’ features that for over a decade have shown tremendous promise but never been fleshed out.

I am thinking (for example) of the ability to use the filter reference form (‘whose’ clauses) on scripters’ own lists, records and objects, or the ability to work with multiple text item delimiters. These things would be a tremendous boost to both scripters and implementors and while such features may not sell any additional iMacs, they might shift a few more high-end machines, and besides surely not rocket science. These features aren’t just scripter fantasies, they are tantalizingly half-implemented. Something about spoiling the ship for a ha’pe’th of tar.

And Sal, or anyone at Apple, can we PLEASE get the Cocoa ‘default’ scripting implementation tidied up and properly documented. (Mostly the ‘Text Suite’) It promises much but in most cases it’s really not doing what anyone wants. Some developers even have the gall to say their app is ‘AppleScriptable’ when in fact it merely has the ‘default’ cocoa dictionary, which is often not even connected up to anything. Apple could take steps to make this less ‘acceptable’.

I respect the need to keep details of unreleased products but we still need to be reminded that ‘something is happening’. That means decent, up-to-date docs, example projects which compile and run ‘out of the box’, and active participation from Apple Engineers on the mailing lists and other online fora. Thank you, Sal, for participating here. It means a great deal more than you may imagine!

And when are we going to get AppleScript on the iPod? ;)

By: James Hober Wed, 11 Oct 2006 20:01:13 +0000 Yes, AppleScript implementation is too hard.

Since pre-history (CodeWarrior PowerPlant) it has always been so.

When OS X was first released it came with a cool program called Interface Builder. Wow, I could wire up a GUI in no time! I told Apple, this is the way you should do AppleScript implementation. Let me wire up a Scripting UI the way I can wire up a Graphical UI.

Well, we’ve since gotten bindings, Core Data wiring of the model, KVC (all great stuff), but still no way to wire up AppleScript support. (I don’t doubt that the problem is hard but solving it could mean an explosion of AppleScript support by developers.)

Suggestions to Apple:

– offer an IB-style way to implement AppleScript.
– offer extensive sample code illustrating anything that can’t be wired up.
– offer great debugging for the implementer and for the scripter (even if it lifts the curtain a little on opaque AppleEvent structures).
– continue to encourage English-like termininology that is as consistent across applications as possible.
– make Cocoa applications automatically recordable with respect to moving, closing and minimizing windows, etc. This means taking some of the recordability implementation for the Finder and moving it into NSApplication or some other Cocoa implementation class. Then we can get base recordability for free and implementers need only make their specialized events recordable.
– fix bugs.

Suggestions to implementers:

– always include example scripts. I stick mine right in the Help documentation that the user can pull down from the Help menu.

– make your terminology as English like as possible and as consistent with other apps as possible.

– make your custom AppleEvents recordable (without trying to do what should be Apple’s job of making moving windows, etc. recordable.) I gave a simple example of how to do that here: where I construct the AppleEvent in Cocoa and use a single Carbon call to send it. Another example can be found here:

– communicate with scripters and find out what they really want. The whole point of AppleScript implementation is for the scripter. We must listen.

Finally, I want to send huge thanks to all who contribute to the AppleScript implementers mailing list. The Apple engineers who contribute there are enormously helpful and do so on their own time! If they haven’t been around as much lately, we can only hope that they are very busy and hard at work making AppleScript better.

By: Allan Odgaard Fri, 06 Oct 2006 17:35:57 +0000 Peter Hosey: At first I was certain that it was an Adium bug, but I later ran into a very similar problem with another application where exactly the same workaround fixed it.

By: Guy O'Rojo Mon, 02 Oct 2006 20:51:52 +0000 Hi:

As a non-programmer bridging the design and database worlds in a production environment, I NEED APPLESCRIPT! Why? Because I don’t think with arbitrary symbols or in dot syntax. I am a logical fellow, I think in English, and I don’t have a degree in Computer Science or Mathematics.

But I do know what I want, and I know how I want it to happen. Applescript is the only thing that lets me automate my processes easily, quickly, and flexibly.



By: Andrew Mon, 02 Oct 2006 15:19:02 +0000 Oh my, I can only imagine the uproar from the prepress industry if Applescript was abandoned for something else. The number of man hours that have been put into Applescript workflows within the industry is simply astonishing. I have personal experience of this both as an application developer looking to add Applescript support to applications and as a user trying to script Applescript workflows. I wholehartedly agree that Applescript needs an overhaul but backwards compatibility is a must.

By: David Moles Mon, 02 Oct 2006 08:49:45 +0000 Or if you wanted something closer to the original syntax:

  cp `find ~/Documents -type f -name "*Smith Project*.doc"` /Volumes/Backup

I’m not sure how the shell (or cp) handles it if the number of files is large, though.