# The first nail in the coffin of Python appscript

Yesterday I noticed that my iTunes info script wasn’t working. This is the script that NerdTool uses to display the currently playing track down in the lower right corner of my Desktop. Like this:

There are actually two scripts at work here: one that gets the album artwork, and one that gets and prints the informational text. It was only the latter that failed. That script, named itunes-playing and written in Python using the appscript library, looks like this:

python:
1:  #!/usr/bin/env python
2:
3:  from appscript import *
4:
5:  template = '"%s" by %s (%d)\n from %s'
6:  info = ''
7:
8:  iTunesCount = app('System Events').processes[its.name == 'iTunes'].count()
9:  if iTunesCount > 0:
10:    iTunes = app('iTunes')
11:    if iTunes.player_state.get() == k.playing:
12:      track = iTunes.current_track.get()
13:      who = track.artist.get()
14:      what = track.name.get()
15:      onwhat = track.album.get()
16:      stars = track.rating.get()/20
17:      info = template % (what, who, stars, onwhat)
18:  print info


It can be run from the command line, and when I did I got the following error message:

AttributeError: Unknown property, element or command: 'player_state'


suggesting a problem on Line 11. Since I had just updated iTunes to version 10.6.3, my first guess was that the new version had removed the player state property from its AppleScript library. But a quick review of the library in the AppleScript Editor (and a one-line script to test it out) showed that player state is still there—the problem is that appscript can’t access it the way it used to.

I take this as the first of a series of failures that my appscript-using programs will suffer as time goes on. As I’ve mentioned here before, appscript’s developer, Hamish Sanderson, has stopped developing appscript because Apple is deprecating certain Carbon libraries it depends on and not providing equivalent functionality in Cocoa. He recommended several months ago that appscript not be used in any new projects.

It may well be that I could tweak itunes-playing to work around the AttributeError, but the effort I’d put into that fix would be, in the long run, a waste of time. Appscript is a dead end; when a script using it breaks, the best solution is to rewrite it in AppleScript or a combination of AppleScript and another language. I’m a little surprised to be forced into this before Mountain Lion, but the failures had to start coming sooner or later.

In this case, the fix was quite easy. Because the information is just a concatenation of several track properties, my Python/appscript program could be replaced with pure AppleScript:

 1:  tell application "System Events"
2:    if name of processes does not contain "iTunes" then return ""
3:  end tell
4:  tell application "iTunes"
5:    if player state is playing then
6:      set ct to current track
7:      set stars to round((rating of ct)/20)
8:      set info to "“" & name of ct & "”" & " by " & artist of ct & " (" & stars & ")" & "
9:  " & album of ct
10:      return info
11:    else
12:      return ""
13:    end if
14:  end tell


This is saved as a Script named itunes-playing.scpt in my ~/bin/ directory. NerdTool doesn’t know how to run AppleScripts directly, but because it can run shell scripts, all I have to do is have it run the shell command

osascript ~/bin/itunes-playing.scpt


The osascript command is one of those wonderful little utilities Apple included in OS X back when it was trying to make life easier for scripters.

I’m not certain how many of my active scripts still use appscript, but you can expect to see more posts like this in the future. And since most of these scripts do a lot of text manipulation—something AppleScript is particularly bad at—I won’t be able to get away with pure AppleScript solutions very often. I don’t see much value in going out to change scripts that are still working, but I’ve been looking into convenient ways to mix Python and shell scripts so I’ll be ready when they do start to break.

Update 6/27/12
The comments are especially good and especially lengthy. If you have any appscript-using scripts that have been broken by the iTunes update, and you really don’t want to write in AppleScript, you can use the technique described below by Matt Neuburg to generate a static “glue” file that will get appscript working with iTunes again. Matt’s provided a glue file for Ruby and a summary of how to use it in his online Ruby/Appscript book. Andrew Barnert has extended Matt’s work to generate glue files for Python, Ruby, and Objective-C and put them into a GitHub repository.

## 49 Responses to “The first nail in the coffin of Python appscript”

1. Clark says:

Ugh. Not looking forward to this. Of course iTunes AS support always was wonky. Scripting Bridge frequently doesn’t work right with it too.

I’m slowly converting over the scripts I use to Cocoa and Obj-C.

2. Marc Wilson says:

Doctor, you’re missing a line to define ‘stars’:

    set stars to the ((rating of ct) / 20) as integer

3. You caught me, Marc.

Before writing the post, but after taking the screenshot, I decided I didn’t need to show the song’s star rating anymore, so I edited the AppleScript to get rid of it. Then when I saw that the screenshot and the code weren’t in sync, I figured it was easier to put the rating stuff back into the code than to redo the screenshot. Plus, it would make the AppleScript consistent with the Python script.

Obviously, when reconstructing the code I left out the definition of the stars variable. I’ve put it back in above. I used a slightly different line than your suggestion:

set stars to round((rating of ct)/20)


Serves me right for trying to pull a fast one.

4. My experience in AppleScripting with iTunes has usually been positive, Clark. Among Apple’s apps, iTunes is the only one for which I can almost always guess the names of the properties and the syntax needed to access them.

5. has says:

@Drang: The iTunes update breaks appscript-based scripts on my 10.6 box too. However it’s not a new problem: Interarchy and FileMaker have been affected for some time.

The problem lies with the ‘ascr/gdte’ (‘get dynamic terminology’) handler provided by the OS for retrieving old-style AETE resources from running applications. Appscript uses this handler to fetch a running application’s terminology at runtime, whereas (IIRC) AppleScript only uses it when compiling a script that targets a remote application over Remote Apple Events.

It looks like something is causing the ‘ascr/gdte’ handler to mistakenly read the application’s SDEF resource (which it converts to AETE format) instead of its AETE resource, and since the (Carbon) application doesn’t contain a .sdef file the OS’s default .sdef is used. As a result, only the default Cocoa Scripting terminology is returned, which is pretty useless for obvious reasons. Given that the affected apps all implement traditional Carbon-style Apple event support, It might be that something is causing the Cocoa Scripting framework to load up and clash with the app’s own Carbon AE support, but that’s just a guess; I don’t know exactly how the ‘ascr/gdte’ handler is implemented or if there are different CS and non-CS versions of it.

If you can replicate the problem using AppleScript over Remote AE, you can file a bug report on iTunes about that as that’s a legitimate issue for them. The chances of them fixing it are still low - Apple doesn’t give a crap about AppleScript - but at least you’ve done what you can. (I’m not going to do anything about it myself, except maybe use Linux more.)

@Clark: iTunes’ scripting support was quite good for an early vintage Carbon app, though it’s been moribund for many years now. As for Scripting Bridge, it’s fundamentally defective by design and breaks to some degree or other on pretty much all apps, so that isn’t a reflection on iTunes.

As for appscript alternatives: AppleScriptObjC is by far the best solution for ObjC/Cocoa users as it lets you write your inter-application code in AppleScript script objects which your ObjC code can then treat just like native Cocoa classes. (FWIW, caveat emptor, etc. - the entire AS/AE stack will likely be dead in the next 5-10 years anyway, ‘superceded’ by canned NSService crap that makes Windows DCOM and Linux D-Bus look good, so enjoy it while you can.)

6. As you’ve probably guessed, “has” is Hamish Sanderson, developer of appscript and author of my go-to book on AppleScript. You might say he’s an authoritative source.

7. I understand the concern around AppleScript’s future: when Lion introduced application sandboxes it wasn’t clear how sandboxed apps would be able to continue to support the level of scripting we’ve always enjoyed in Mac OS X.

Fortunately, Apple understands these concerns and agrees that AppleScript is important. Their challenge has been trying to find a balance between making the platform more secure and maintaining the scripting functionality we’ve all come to appreciate.

I highly recommend anyone interested in the future of AppleScript watch Session 206 - Secure Automation Techniques in OS X, which was just posted yesterday.

After watching that session last week at WWDC, I now feel confident that we can deliver sandboxed versions of all of our apps without losing any of their scriptability. And because Apple went to the trouble to fix all those issues (rather than simply ignoring them, which would have been much easier for them to do), I feel confident about the future of scripting itself on the platform.

8. has says:

@Ken: Apple have no choice but to ‘secure’ the AE mechanism as best they can for 10.8 as the alternatives would be either to leave gaping security holes in the OS or else remove it immediately without going through the standard Legacy->Deprecation->Removal process, neither of which is a realistic option. Therefore, Apple doing this work says virtually nothing about AppleScript’s actual health or future prospects. Looking at AppleScript in isolation, noticing that it’s completely business as usual, and so concluding that all is well is to massively, egregiously miss the point; you have to consider AppleScript as part of the larger OSX/iOS ecosystem, and when you do that it’s pretty clear that the entire AS/AE/AEOM stack is already effectively Legacy technology, either explicitly or implicitly.

The AppleScript user base has been stagnant for years. Over the same period, the OSX/iOS user base has seen mind-bogglingly meteoric growth. Traditional pro markets (music, video, print, etc; i.e. the folks that once justified AS’s continued existence) are no longer key ares for Apple; the only pro market that really matters to it now are the ones who put apps in the App Store, i.e. professional OSX/iOS software developers. We’re already seeing new IPC mechanisms emerging in the form of low-level, task-specific, programmer-oriented APIs, e.g. 10.7 introduced XPC Services and 10.8 will no doubt bring more of that sort of thing. The vast majority of professional programmers already (and not entirely without cause) regard the whole AppleScript/Apple event system as damage to be routed around, so will be only too happy to adopt these new systems, regardless of what other limitations they might have.

So, AppleScript itself remains static while everything else is rapidly changing and massively expanding all around it, which means AS’s percentage share of the iOS/OSX market (and therefore its importance and influence on both key Apple decision makers and third-party developers) is in significant decline. It may have a long tail as software life cycles go, but make no mistake: AppleScript’s finest days are behind it; its best opportunities for improving itself, enlightening developers, and acquiring influential friends sadly frittered away. Eventually the relentless, inevitable march of iOS-dictated progress will roll straight past - if not directly over - it.

Personally I wish Apple would Legacy the entire AS/AE stack ASAP, ideally in 10.8, allowing at least a bit of time to establish a roadmap for its methodical replacement. There are some really great concepts underpinning AEOM and an enlightened UI-centric philosophy binding it all together, even if the actual implementation only rarely lives up to those promises. It would be nice to see at least some of its better ideas carried over to its successors, but I fear this will be less and less likely to happen the longer that app developers are left to do their own ad-hoc low-level proxy API thing - once those cats are out of the bag they’ll be nigh impossible to stuff back in.

9. Clark says:

I still have confidence that by necessity Apple’s going to come up with an alternative to Applescript. There are two main reasons for my faith.

First Apple needs a general messaging system. Especially with iOS where applications tend to be mono-focused. This is right now the #1 limit on iOS. iOS6 has some hacks to get around this for film, twitter and Facebook. But Apple knows that’s insufficient. Also Windows 8 does a good job here (or at least a better job) and even Android does more than iOS. If you have a general messaging system you’ll want to put in place (or at least think of ahead of time) the structure of that messaging.

Second it’s inevitable that iOS will take away from the Mac market all those who don’t need the power of OSX. For those people the only real advantage of OSX would be a real keyboard in the Air. Apple then has two choices: either abandon OSX or target it at the audience for whom iOS isn’t enough. That will lead naturally focusing in on more advanced features in OSX as opposed to what iOS targets. Right now we’re seeing the attempt to unify some key features. (I was actually surprised that we haven’t yet seen a gps + maps option for the Air - especially now that Apple doesn’t have to worry about Google licensing restrictions) Once we get some maturity in iCloud and have feature parity in base features we’ll see OSX pro users get more love. (Or OSX will just be dropped, as I mentioned - which really isn’t likely)

10. Clark says:

BTW - regarding Scripting Bridge. There are a few things I like but yeah, by and large it’s a mess. Worst you can’t really figure out how to represent an existing Applescript with Scripting Bridge (whereas with Appscript it was pretty easy most of the time).

I’m really curious to see what Numbers is like when it gets released. (Probably a few weeks after Mountain Lion) If it has the same dictionary (or lack thereof) as the existing Numbers I’d say Applescript is not long for this world. If they add necessary Applescript features (right now you can’t even create a document) then we know that an alternative probably is a ways away.

11. has says:

@Clark: Cross-process messaging (e.g. Apple events) and end-user programming (e.g. AppleScript) are two orthogonal (albeit complementary) issues. It makes sense to consider them separately since Apple may tackle them in completely different ways (e.g. by actively providing app developers with lower-level alternatives to Apple event-based messaging, while leaving the AppleScript language to wither on the vine much as they did with Hypercard).

1. Apple are already coming up with alternatives to Apple events (XPC Services, etc). Like I say, these are low-level, task-specific, programmer-oriented APIs provided on both OS X and iOS, allowing ObjC-based application A to tell ObjC-based application B to perform some predefined task. They’re not designed or intended for use by end-user scripters and other riff-raff. All they do is meet a single developer need as that need arises. As long as Apple make it fast and easy for app developers to write the code needed to exchange that canned data between apps then those developers will be happy. The average app just wants to perform a few canned operations like firing off an email or fetching a track list out of iTunes, or talk to its sandboxed subprocesses via its own private and entirely arbitrary APIs. Why would those apps’ developers spend months crafting a finely polished general-purpose interface when a quick-n-dirty hack fills that need?

Okay, so there are a few enlightened apps (e.g. Adobe CS, MS Office, Omni) that recognise the value of providing a high-level general-purpose interface for end-user automation, and for those particular developers the cost-vs-benefit may justify the additional time and work required to build out all that extra functionality. However, those apps could still provide a significant portion of that value via embedded interpreters (e.g. Adobe embed JavaScript in Photoshop, InDesign, etc), and at a lower development cost. Sure, end users lose most or all ability to do cross-app integration, but, as AppleScript has demonstrated, the more powerful and sophisticated and higher level one tries to make a cross-process messaging system, the harder it is to get its design and implementation right, and the smaller the proportion of app developers who are sufficiently talented to use it well.

Witness the popularity of degenerate SOAP over the sophisticated elegance of RESTful HTTP (which, like the Apple Event Object Model, approaches it as a UI design issue.) Any lazy, ignorant code monkey can throw together a SOAP API - sure it’s absolutely horrible but it fills the immediate need. Whereas crafting a really good REST API takes a lot of learning and experience, planning, development, review and refinement, and most devs suck at it. (Most ‘RESTful’ HTTP interfaces are nothing of the sort; REST rivals even the AEOM in the Developers Who Utterly Fail To Get It stakes.) And if building the user interface itself it hard, imagine how much harder it is to build the framework used to build those interfaces.

1. I can’t see them creating an alternative to the AppleScript language itself. Apple don’t much care about scripting languages any more, since those don’t put apps in the App Store, and every feature they add to the OS these days is driven by that. Their support of popular mainstream OSS languages such as Python and [Mac]Ruby is lukewarm at best; I can’t imagine why they’d want to create a brand new scripting language from scratch (a niche product), never mind an end-user oriented language to directly replace AppleScript (a niche within a niche). It takes about a decade for a new language to become successful - designing the thing is easy, it’s building a large, self-sustaining ecosystem around it that’s the hard part. They’d just be creating a ton of work for themselves, and for what payoff? Most new languages never hit the big time, and Apple’s previous forays into inventing languages (Hypertalk/AppleScript, Dylan) have hardly distinguished themselves. If Apple do anything at all in the language area, it’ll be to create a ‘managed’ version of ObjC to protect the average developer from the nastier, unsafe parts of C, comparable to MS creating C# to protect their average developers from the nastier, unsafe parts of C++ .
12. has says:

(stupid markdown; that should’ve been numbered 1 & 2)

13. Clark says:

Cross-process messaging (e.g. Apple events) and end-user programming (e.g. AppleScript) are two orthogonal (albeit complementary) issues.

True, but if you are enabling a robust messaging then they are fairly closely related. Certainly Apple might just do a half-assed job of it. However I think it’s important enough that they’ll do a good job.

My personal view (perhaps erroneous) is that the main reason things have been a mess is because no one higher up at Apple has communication (Services, Applescript, etc.) as a priority. Thus if it gets any attention it’s someone lower down largely doing it on their own (and maybe bringing a couple other people from their team). As soon as they are shifted somewhere else then it ends up dropped. Witness PyObjC and MacRuby for instance.

For the record I find Applescript an abhorrently horrible language. The joke of it being read only has a lot of truth to it. It’s my least favorite way to code. Were I to propose a system to replace it I’d probably suggest something tied to JavaScript since Apple already has a great JS interpreter, its a well known language, and it shouldn’t be too hard to sandbox it. While I’m not a JavaScript fan to say the least it would still be head and shoulders better than what we have now.

Alternatively we could switch over to something like F-Script (which I’ve honestly never used)

I actually do recognize that few need scripting. And those who do, power users and people doing small and mid sized business, haven’t exactly had the love from Apple. However I think the logic of the market and the distinction between iOS and OSX demand that they’ll retarget those markets. (Although I certainly recognize that it may go the way of the Mac vs. Apple// distinction - I just can’t see Apple abandoning the OSX market to Microsoft)

14. Clark says:

To add, the big problem with Apple’s languages (Applescript, Hypertalk, Dylan) was that they were all oriented around getting regular people to program. The problem is that regular people don’t want to program. They’d have been much, much better off thinking of what would allow power users to make things better for regular users. (i.e. similar to yet radically different from Microsoft’s IT focus)

NeXT for all its problems got this. Right now though there really isn’t anything for power users in this arena. Now it may well be that Apple abandons to pro market for real. I don’t think they want to do that although it’s undeniable they’ve made a slew of mistakes the past two years in that regard. (Culminating in the whole MacPro mess which was the last straw for many power users)

I still think they’ll get this right though. However their existing items of focus (iCloud, sandboxing) have turned out to be much, much harder than they thought. I doubt we’ll see anything until those are mature.

15. has says:

@Clark: The AppleScript language has some fairly egregious design flaws: it allows arbitrary keyword injection by apps and osaxen, it lacks a native module system and its attempts to disguise the differences between the native language runtime and remote application interaction are half-baked and tend to cause as much confusion as they solve. Anything else - e.g. lack of features and poor performance - is merely a consequence of it not building enough marketshare to justify that work, and not a fundamental failing of the language design itself.

At its heart the AS interpreter roughly comparable to a JavaScript interpreter of similar vintage, albeit with a much less dynamic runtime (e.g. [script] object structures are fixed at compile-time, which is fair enough). And the Hypercard-inspired keyword-based syntax is in principle a very good thing. I’ve done end-user language design myself, and one of the things that struck me when teaching it is just how poorly non-programmers cope with punctuation - the parentheses, commas, etc. that make up more traditional Algol/Lisp-inspired syntaxes. English culture biases aside, keyword-based syntax is pretty much self-documenting at that level, which is why AS code has such terrific high-level readability: anyone can look at an AS script and get a general idea of what it does.

The problem is that AS’s low-level readability - i.e. the exact details of how it does it - sucks. This is entirely a consequence of the arbitrary keyword injection and unclear boundaries between the language itself and its built-in AE bridge, which obfuscates the language semantics something awful. It’s impossible for users to learn what every keyword means, and that meaning can change at any time if an app or osax decides to redefine it.

These problems could’ve been avoided had Script Editor been built as an intelligent structure editor a la Alice, since that would’ve kept users right on the semantics and allowed (e.g.) safe use of white space in all keywords and variable names without the need for nasty backfiring compiler trickery. I know traditional programmers have a hard time seeing the value of whitespace in identifiers (or whitespace of any sort; e.g. see Python haters), but is is possible to do it completely safely and legibly (I did), and it is great for making a language appealing and pleasant to non-geeks. Sure, they’ll still have to learn all the traditional programming semantics as they go, but it makes all the difference in them getting their foot in the door in the first place (e.g. had it not been for AppleScript’s friendly face, you would never have had appscript).

So, AppleScript’s heart was in the right place, even if the actual execution was flawed. And that, I suspect was largely due to a lack of time and resources, which in turn is probably inevitable in business since there isn’t a huge amount of money to be made in end-user programming. I think the best chance of seeing innovation here is from academia - e.g. Alice and Scratch are Carnegie Mellon and MIT projects respectively. Unfortunately, those tend to focus on teaching kids to program so aren’t designed for use as general productivity environments, but similar tools could be.

Ultimately, I think they key is to treat end-user programming as a UI problem, at which point it becomes part of a natural continuum along with GUI and CLI, workflow/dataflow programming, Siri, Ubuntu HUD, and the likes. Look at Apple’s Automator, which was a decent idea but again too compartmentalised - too apart from the user’s normal operating environment. But imagine if it’d been provided from the get-go as a native AppKit feature alongside all the usual buttons and windows: stuff like Mail rules and iCal alarms would’ve been built on it, and suddenly users have got a far more powerful tool at their disposal. And because it’s driven by their needs (notifications are a natural driver of dataflow), they wouldn’t think of it as ‘programming’ either; they would just see it as what users naturally do.

This is the promise that the original 8-bit home micro revolution offered, and it is an appalling failure of vision that the GUI’s vision of ‘customisability’ barely stretches beyond changing the wallpaper on the desktop. Those 8-bit guys had the intention but not the tools to truly deliver on it; now we’ve tools aplenty but not an ounce of imagination to go around.

So this is what Apple should be doing to ‘replace AppleScript’, while still fitting in with their whole ‘Siri as automation for the masses’ philosophy. But they won’t, because they don’t really have grand visions any more (they used to, and it damn near killed them in the early 90s due to failure to deliver). Instead, they look for the shortest line between point A and B and take that (and profit immensely). Which is why you won’t see an AEOM-level replacement to the existing AE infrastructure either, because that requires a lot of work to an open end. Instead, they’ll ask ‘What does Siri need this week?’, to which the answer might be ‘an easy way to send an email’, and they’ll throw in a new Cocoa method dedicated to that particular task, and they’ll keep doing that until there are a thousand such methods and no overall philosophy or consistency to any of it. And the longer this quick-n-dirty approach goes on delivering immediate results, the more influential friends it wins, and the more pointless the AE/AEOM stack looks due to the AS team’s years of miserably failing to get its act together.

And that is the future, as Apple continues to merge OSX and iOS into a single outwardly consistent system. A key aspect of its internals degenerates into a broad yet limiting sprawl, and end users end up with a canned predigested external environment. And the Us and Them division between users and developers becomes even more deeply cut. Absolute crying shame, because with a time machine to go back over the last 20 years and make a few modest policy and technical tweaks and convert some friends in the right places, Apple could’ve delivered on it all.

I’d tell you to get off my lawn now, but as this is actually Dr Drang’s lawn I’d best remove myself before I take it over entirely.

16. has says:

Okay, just one more thought: Automator as gateway drug was a great idea, completely screwed by an utterly obsolete delivery mechanism. Automator should never have been implemented as a standalone application; instead, its GUI should’ve been packaged as an NSControl that any old app developer could drop into their application, hook up some ‘pipes’ to trigger workflows, and throw in a few free actions that perform common tasks in their app. Any time an app needs to provide stuff like notifications (Mail rules, iCal alarms, iTunes track changes, device mounts, RSS updates, etc), just wire it to a pipe. The framework could’ve also injected a free ‘Custom’ menu into the menubar, allowing users to trigger selected workflows from there as well. Hooking this up should’ve been second nature to app devs. And to users, whose lives are also driven by notifications, the purpose of thing would be immediately apparent.

Fashionable talk these days is of ‘gamification’, and this approach would’ve gamified the crap out of applications. And since Automator is Cocoa, not Apple event, technology, it would’ve carried easily over to iOS as soon as there was political will to do so. Instead, the Automator app sits quiet and ignored in the Applications folder - an alien thing apparently intended for Somebody Else to use - while the vast mass of regular users spend their entire lives in Safari, iTunes, Mail, Skype, etc. (or their iOS equivalents) and never even know what they’re missing.

Alas, every time I count up the number of ways the AppleScript team have screwed up their stewardship of Mac automation over the years, that number seems to increment automagically. I really should stop.

17. Matt says:

A computer where appscript cannot script iTunes is not a world I want to live in. Fortunately I can solve the problem for now by restoring an older version of iTunes.

None of my appscript scripts can be “translated” into AppleScript; they rely on Ruby features (I use rb-appscript, not py-appscript, but it’s the same sort of thing).

@Ken: It’s not what you can do but what your users can do that matters. If you have users that want to script your application using appscript, and if they can’t because sandboxing breaks appscript, then your application is dead to those users. Don’t get all happy-clappy about sandboxing just yet.

@has: Maybe we could add code to appscript to fetch the dictionary in some other way? I mean, Script Debugger isn’t broken by this latest version of iTunes, so surely appscript needn’t be.

18. Matt says:

@has: Or maybe there’s some way to instruct the existing rb-appscript to fetch the dictionary from my older copy of iTunes and then redirect subsequent messages to talk to the newer copy?

19. Matt says:

Never mind, I see how to solve it. These are Ruby instructions, but the same sort of thing works for Python.

• Launch the old version of iTunes (I’ve renamed my copy iTunesOld) and run this script:

require 'appscript'
Terminology.dump("iTunesOld", "Tunes", '/Users/mattleopard/Desktop/tunes.rb')

Of course you need to fix that pathname so it works on your machine. Okay, now tunes.rb contains a dump of the iTunes terminology.

• Quit iTunesOld and launch the real iTunes.

• To script iTunes from now on, talk like this:

require 'appscript'

dump = '/Users/mattleopard/Desktop/tunes.rb'
require dump

itu = Appscript.app("iTunes", Tunes)

#now let's test it
itu.selection.get # woohoo!

Now you can throw away the old copy of iTunes; it’s done its work.

What this really proves is that appscript is the coolest thing since sliced bread. Cooler, since does sliced bread give you the tools to slice itself?

20. Matt,

I took a stab at editing your code so it would look good here. Let me know if I screwed something up in the process.

I’m going to gently suggest that you’re fighting a losing battle by trying to hold onto appscript. Your scripts can be translated into a combination of Ruby and AppleScript by either

• writing the script in AppleScript and using do shell script to handle the Ruby parts; or
• writing the script in Ruby and using backticks and osascript to handle the AppleScript parts.

Edit But of course you know how to mix languages. I wrote this before seeing your email address and realizing that you’re Matt Neuburg. I’m not used to celebrities showing up in my comments. Should’ve guessed that only someone from my generation would use Tom Terrific as an avatar.

I stand by my “losing battle” comment, though. At some point, resurrecting old versions of software to extract their vocabulary is going to be untenable.

21. has says:

@Matt: You are correct; a static glue provides a workaround, at least for now. It was never a sandbox issue: Interarchy broke with the same problem several years ago, and FileMaker more recently. Most likely, it’s a conflict between Cocoa Scripting and the traditional Carbon AEOM support of the applications in question (which CS has no business with in the first place). iTunes is the first case where a ‘core’ application has failed; it was only a matter of time though before this happened.

Sure, you could could recode appscript to use OSACopyScriptingDefinition instead of ascr/gdte events, but as with everything the AS team has developed in the last decade, OSACopyScriptingDefinition and the SDEF format is riddled with flaws. And even then, you’re still only delaying the inevitable. I actually did consider publishing static glues on the appscript site (which I still control), but in on reflection decided against it. Appscript was designed with multiple layers, and multiple fallbacks, to protect against technical failure (harsh experience learned me to build it like a brick shithouse), but in the end the failure that killed it wasn’t technical, it was human.

I am genuinely proud of appscript; I believe it did right by the original AS team’s vision. I am happy to credit my own contribution here, though don’t underestimate AppleScript and appscript users for keeping me right and in my place along the way. But it failed to build significantly on that vision; ultimately, it fell into the old OSS trap of ‘it scratches my itch, and that’s enough’. It was a technical success, but a popular failure. Had I worked harder at community building, had I worked better with other appscript evangelists, we might have created a self-sustaining community of professional programmers, converting an audience who traditionally hated the entire AppleScript stack into true believers.

OTOH, looking back, it’s pretty obvious that by the time we were hitting our game we were already too late to make a difference. Things were already screwed up on the server side when some poor Cocoa sap got lumbered with creating Cocoa Scripting. It took years to iron out even its trivial flaws, never mind its most egregious design errors, which are baked into its core. Apple’s failure to provide a client-side bridge for years after that meant that uptake amongst traditional developers - without whom there are no scriptable applications, no professional credibility - was also stalled. And when they did, belatedly, produce their own bridge, it sucked - and the excuse was (when you reported the first application compatibility fault a few days after Leopard’s release) “we didn’t design it to do that”. Bear in mind, the whole reason I created appscript was because traditional OO developers didn’t understand how AppleScript worked, so inevitably designed their bridges wrongly. Py-appscript was written as response to Bob Ippolito’s failure to get aeve to work correctly; rb-appscript in response to Laurent Sansonetti’s mistakes in writing RubyOSA. And objc-appscript was created pre-emptively, because from the moment I heard about Scripting Bridge and what it was, I knew that Chris Nebel has completely failed to learn from the mass of prior art, both good and bad, stretching all the way back to Userland Frontier. Frontier and Mac::Glue were the only bridges that got it even half-right before me; perhaps not surprising since they were the only overtly non-OO platforms, and so more likely to grok - and accept - AEOM’s semi-RESTful RPC + relational query nature for what it is.

The fact that some unknown middle manager ultimately decreed that OS X 10.5 should ship with only a single one-size-fits-all bridge (that sucked equally on all languages), back when appscript was still being considered for inclusion, was merely the icing on the cake. (The fact that they also considered RubyOSA, and even included it in some developer builds, suggests that they never truly understood just what appscript offered - not merely a bridge that genuinely rivalled AppleScript’s own, but also a nascent user community and active evangelists of the sort not seen since Cal Simone saved AppleScript from the NeXT barbarians and philistines in what has since turned out to be a sadly Pyrrhic victory.) It would be easy to blame Chris N and said manager for almost everying, and me for the rest - but while we do bare a decent chunk of responsibility, in the end the root failure is bigger even than us.

The fact is, 99% of the programming world doesn’t want appscript, it doesn’t want AppleScript, or the AEOM, or anything else beyond predigested sanitised lowest-common-denominator slop. Look again at SOAP: the whole reason it’s so damn popular is because it allows barely literate programming ‘professionals’ who have zero interest in the Fallacies of Distributed Programming to believe that they don’t need to know squat about network programming in order to do their jobs. And in a way they’re right: their solutions suck beyond belief, but they meet the client’s ‘specification’, which is ‘good enough’. And since nobody knows any better, they conclude that’s the best that can be achieved, and blame all the suckery on the tools rather than the craftsman. Ignorance is bliss, and that’s exactly how Apple’s key decision makers are feeling today. So appscript is already boned, and AppleScript boned not far behind it; and the longer that they linger, the less motivation there will be for creating a decent replacement, because by then the weeds will have taken over, and no-one left will be any the wiser for what might’ve been.

Geeks tend to focus on the technical merits alone, and fail to account for the human factors which are the real deal makers/breakers (because that’s not what they understand). Whatever the technical merits and errors of AppleScript might have been, it was ultimately screwed by human failure. Without influential fans, the best technology in the world isn’t worth squat. So the whole damn AS stack needs to die quickly, and in an organised fashion that salvages at least some of the philosophy and concepts behind it. The longer it drags out, the worse whatever replaces it will be.

AppleScript is already dead, even though it might not realise it yet. It may continue twitching for years to come, but it no longer carries any influence in shaping the future. What matters now is organising whatever folks are left to ensure that whatever iOS-motivated solution supersedes it doesn’t suck any more than it absolutely has to.

22. has says:

Oops, should’ve read: “You are technically correct…”

Also: “a computer where appscript cannot script iTunes is not a world I want to live in” - what, seriously? Dude, please don’t make the only guy who has less of a life than everyone else in the world have to tell you to get one yourself… ;)

23. has says:

Drang: “I’m going to gently suggest that you’re fighting a losing battle by trying to hold onto appscript.”

@Drang: Matt [Neuburg (if I’m not mistaken)] is absolutely correct in his technical workaround: Appscript will still function with iTunes 10.6.3 if supplied with a static glue.

Philosophically, however, I entirely agree with you. The well is completely poisoned, and the longer folks continue trying to sup from it, the sicker they will end up being. The entire AS/AE/AEOM stack is fundamentally, irrevocably screwed, but if you really have to, sticking to the Apple ‘supported’ options will at least delay the inevitable for a few more years. So AppleScriptObjC and osascript are your friends now (I won’t dignify SB beyond calling it a defective, obfuscated bag of balls which might suffice for trivial tasks in a pinch).

24. Matt says:

@Drang thanks for the edit, I was hoping you’d do that

25. Clark says:

Wish Apple had hired you. I was pretty unhappy with a lot of how Applescript was dealt with in the early days. Although honestly it faired better than most Sys9 technologies. Remember publish and subscribe? When the NeXT took over Apple there was a lot of stuff that just didn’t fit with their view of things. A lot was understandably tossed. Some grudgingly became Carbon.

I’ve finally been learning Cocoa finally. I wished I’d done it years and years ago. It’s way better in many ways than I thought. It’s very different from what I remember from my old Powerplant days. I can however understand why the ObjC people didn’t know what to make of AppleScript and perhaps weren’t interested to learn.

It’s somewhat sad as AS really did have some very cool features. (Although some of them Apple didn’t exactly make easy for developers to use) I remember when it was language agnostic and there was even a JavaScript language module for it.

But for all it’s strengths I think it’s clear Apple is now ObjC centric and AppleScript isn’t something they get. I don’t think the issue is scripting and automating apps but doing so it that smalltalk style.

Automator is a hack but a useful one. 80% of what people would write AppleScript for they can now do without having to code. (Heck, I deleted a bunch of code for handling bulk image processes that Automator handles). The problem is of course that a lot of things it doesn’t do.

However if they design inter-application communication I bet it’ll be done by one of the more competent teams doing the fundamentals of Cocoa. It might lack some of the strengths of AppleScript but I bet it’ll integrate very well into the overall application framework. Which frankly AppleScript doesn’t which is partially why so few developers bother to add it in a robust way. (Typically the few apps that offer AS re graybeards in some way)

26. matt says:

Okay, I’ve added instructions for using a static iTunes dictionary at the end of Chapter 4 of my online rb-appscript book:

http://www.apeth.com/rbappscript/04appobject.html

I’ve supplied the static glue in this case. Of course this feels like a step backwards (static glue? shades of Perl and Mac::Glue, gag me with a spoon) but it gets us up and running again with scripting iTunes, which is all that matters. (@has, this is how I get a life!)

BTW, @has, I can’t help speculating whether reverting to rb-appscript 0.5.3 wouldn’t have solved the problem as well. IIRC, it used a different way of getting the dictionary. Of course, that way may be deprecated, but the current way is busted (on iTunes)…

Finally, I just want to say, @Drang, I wrote a fairly ground-breaking book about AppleScript, so I know what it’s like as a language and as a programming milieu, what it can and can’t do, etc.; and I personally would never want (or even be able) to do with AppleScript what I do oh-so-elegantly and nimbly with Ruby and rb-appscript.

There’s a good list of what’s wrong with AppleScript in the intro to my online book (http://www.apeth.com/rbappscript/00intro.html). I could show you a five-line Ruby program using Appscript and challenge you: “How would you do that with AppleScript?” Sure, perhaps it could be done somehow, but it wouldn’t be easy. Or pleasant. Or elegant. Or maintainable. Or…

27. First, Matt, I own your book (the first edition, even) and have complimented it in an earlier post. You don’t need to puff yourself up around here.

Second, I never said—and never would say—that what can be done with Ruby/Appscript or Python/Appscript can be done with AppleScript alone. As I said in the original post (about 7000 words up the page) this particular script could be rewritten in pure AppleScript because all it did with the info it extracted from iTunes was concatenate it. As I said in my comment, rewriting most Appscript programs will need a combination of AppleScript and Ruby or AppleScript and Python.

Is this an elegant solution? Of course not. If it were, people like you and Clark and me would never have bothered with Appscript in the first place. But given that Appscript as we knew it is dying, elegance is no longer an option. You’ve just given readers of your online book a hack to keep using Appscript with iTunes, but that won’t help them with FileMaker or other applications that break the method by which Appscript gets their dictionaries dynamically.

The only solution that will continue to work for all applications as long as AppleScript itself is supported is the language combination technique: render unto AppleScript that which AppleScript does best, render unto Python (Ruby) that which Python (Ruby) does best, and use one language to call the other.

28. Matt says:

break the method by which Appscript gets their dictionaries dynamically

Yes, but that’s a contingent fact. There’s other ways to get dictionaries. iTunes didn’t break the ability of AppleScript Editor, Script Debugger, or AppleScript itself to get its dictionary. It broke one rarely used method of getting a dictionary. No law says that appscript can’t use some other way.

29. has says:

Matt: “I could show you a five-line Ruby program using Appscript…”

@Matt: Hell, I could’ve shown you a 25KLOC Python program that’d make every last AppleScripter (and quite a few ‘real programmers’ too) on the planet weep emerald tears of burning jealousy, enough to fill an ocean. That was one of the great things about appscript: it scaled brilliantly because the host languages (and their surrounding ecosystems) scaled brilliantly, in a way the AppleScript platform never could. It was never actually better than AS at talking Apple events, but it was less than a hair’s breadth away. It just did its job correctly, with a minimum of fuss, attitude or smart-assery, and left the host languages (Python, Ruby, MacRuby, ObjC, etc.) to get on with promoting their own myriad virtues.

“There’s other ways to get dictionaries.”

Rb-appscript has always used ascr/gdte events to build dynamic glue tables. Older versions’ dump() methods used OSAGetAppTerminology() to generate static glues, but that function was deprecated (which would’ve prevented apps that used appscript being accepted by App Store) so was changed to use ascr/gdte events as well. In any case, OSAGetAppTerminology() only works for local apps; ascr/gdte events are still used when obtaining terminology from remote apps (which is why I suggested confirming that AppleScript also breaks when compiling scripts that target apps over remote AEs, and filing bug reports on the guilty apps on that basis).

Sure there are other ways to get terminology in SDEF format, but that has bugs and inconsistencies of its own and is a pain to deal with by comparison (bloaty, unstable format, XInclude nonsense, buggy automatic AETE->SDEF converter, etc); I did try writing an SDEF parser once but gave up fairly quickly since CFXML wasn’t remotely up to the task and an lxml dependency would’ve created problems of its own. AETEs are fast, simple and reliable to parse.

It’s just unfortunate that something (most likely Cocoa Scripting, another product of muppets) is screwing up ascr/gdte handler behaviour in certain Carbon apps. The correct solution is to file bug reports on those apps and get Apple to fix that problem. But good luck with that.

All of which misses the point: the whole AS/AE/AEOM stack is legacyware anyway, meaning none of it is in particularly good health or has a promising future ahead of it. And appscript, having already been through the whole Apple embrace/reject/crap-on process, has seen its day and is in an even more fragile position. Sure, if you already have significant systems built on it, you might as well try to maximise your ROI by keep those running as long as practical. But it’s a loser’s game to start any fresh investment in it now. iTunes breaking is just one more sign of things to come. The Apple-sanctioned alternatives (AS/ASOC/SB) may be less than stellar (ASOC being the best, or least awful choice, in situations that allow it, i.e. ObjC-based apps targeting 10.6+), but at least Apple is doing all the hard work of keeping them limping along.

As far as I’m concerned, Apple should:

1. Grow a pair and publicly declare the entire AS/AE/AEOM stack legacyware as of 10.8, and put together a roadmap for its total replacement over the next 7 years.

2. Tell the entire AS team to pursue other career paths (I would suggest Democratic party candidates, another group with a talent for seizing defeat from the jaws of victory). I suspect they perform little useful function these days beyond collecting paychecks and warming chairs, and are now part of the problem, not the solution.

3. Use the freed up resources to recruit a couple new broad talents - say one HTTP+REST guru and one 0MQ veteran, who between them can bring a wealth of fresh insight and perspective to the problem. Don’t tell them how to do it; just tell them what the essential requirements technical and usability requirements are and let them figure out what’ll work best.

Have this new blood work in alliance with the XPC Services and network and security folks to figure out and build a new IPC framework that is designed from the ground-up to operate in modern OSX and iOS environments, where every process is sandboxed and potentially unfriendly. Stick a much simpler, programmer-friendly alternative to AEOM on the server side - say, a very thin conventional OO-based DOM-style abstraction with an XPath/XQuery engine included for convenience - and then produce utterly comprehensive and first rate developer and user documentation and design guidelines so that everyone - both app devs and users - understand correctly exactly how to use it.

No, the result wouldn’t be ‘AppleScript’ as we know it, but it might manage to salvage at least some of the original AS team’s philosophy, and it would have a decent chance at gaining mass traction amongst all OSX/iOS developers, as without their buy-in no high-level IPC system can ultimately survive. The spineless alternative is to leave the AS/AE stack to slowly and quietly rot away over the next decade like they did for Hypercard, leaving an ongoing power vacuum into which all manner of inconsistent, incoherent, low-level ad-hoc single-purpose APIs with no standard design/interaction/security/documentation model sprout like weeds. Which is already happening.

30. matt says:

Well:

• I really like fetching the dictionary at the time I form the application object (rather than relying on previously saved “glue”).

• The sdef tool is available at the command line, and fetches an sdef version of the dictionary regardless of what format it’s really in.

• The sdef tool works on iTunes 10.6.3.

• The structure of the module created by Terminology.dump is clear.

So I’ve written a simple Ruby routine that accepts an application filepath, calls sdef on that application, parses that sdef into the very same format that would have been created by Terminology.dump, and returns the resulting module. So now I can use the second form of Appscript.app and fetch the dictionary on the fly, like this:

    require 'sdefToRBAppscriptModule'
require 'appscript'

Tunes = SDEFParser.makeModule("/Applications/iTunes.app")
itu = Appscript.app("iTunes", Tunes)
p itu.selection.get # it works!


Problem solved? Time will tell, but things look good for now.

31. abarnert says:

has says “AppleScriptObjC and osascript are your friends now”. I disagree.

For a brand-new project, I might use ASOC, but I don’t believe there’s much point in converting anything beyond trivial scripts. Not that appscript isn’t a dead end, just that ASOC and osascript are just as dead, and AppleScript itself isn’t far behind.

First, while they may well deprecate the AEM in 10.9 and remove it in 10.10 (or OS XI or iOSX or whatever), that’s 2-3 years off, and there’s certainly no guarantee that ASOC will still exist in the same form (or that there will still be apps worth scripting). So, you might as well wait until you might have to do it, instead of speculatively doing all the effort today.

Second, if you’re using scripting in an app that you want to sandbox (e.g., to get it into/keep it in the App Store), you can’t use osascript, and you can’t use OSAC to interact directly with your native (or PyObjC/MacRuby) code. Even if you’ve got static, standalone scripts that fit the model for sandboxed scripting in 10.8, unless you’re willing to drop 10.7 immediately, you’re still going to need the exact same temporary exception entitlements as if you’d stayed with appscript. Really, your only viable option is to convince Apple that whatever specific thing you’re trying to do (e.g., browse the user’s media library) should be doable from the sandbox, and you need to continue to use scripting temporarily until they provide some nice sandbox-friendly API to do it. In which case you might as well stick with appscript until then.

Anyway, Apple is adding those nice sandbox-friendly API (NSSharingServices, the AV player stuff that replaces scripting or embedding QT, probably some iOS-style media library APIs, etc.), and will continue to do so until they’ve removed 70% of the need to script all of the core apps. Third-party apps that don’t really “need” scripting, just IPC between two specific apps, will use XPC, application groups, etc. instead. Many third-party apps will move to idiosyncratic internal scripting (MS Office already went back from AS to VBA in 2011, Adobe CS already has a Flash VM inside, etc.); others will add some mediocre web services, command-line, or dylib API (ala uTorrent). And then Apple can drop AS with no replacement. And all those Linux people who wanted to catch up to OS X in the user friendliness and consistency of automation will finally have their wish…

32. has says:

[OK, final response; I’m trying to be retired, folks:]

@abarnet: I’m not saying rewrite all existing appscript-based scripts for the sake of it: those are already a sunk cost so you might as well recoup what value you can from them. But be prepared to rewrite them when they break, and use AppleScript for new projects where at all practical.

Beyond that, I agree with your pessimistic assessment of what’s in store for the OSX/iOS platform. Which is why I want folks to stop lingering on appscript, which is already dead, and start thinking about what, if anything, can be done to mitigate the approaching damage you describe.

The immediate move should be to regroup what people you have on what little firm ground there is, which is the excellent Apple event support and associated braintrust provided by AppleScript and its community. ASOC presents AppleScript in the best light possible for ObjC developers, as it allows them to write their IPC code in AppleScript (which it’s great at) and use ObjC for everything else (which it’s great at), and it allows them to directly leverage the AS community’s considerable knowledge and experience in manipulating specific applications to produce effective, efficient (and maybe even elegant) code that squeezes the absolute best out of AE technology.

Forget SB and appscript: SB could never do that, and appscript no longer can. Effort spent on them is effort wasted (and necrophilia unseemly besides). And the AS/AE/AEOM platform will eventually go the way of Hypercard, so it’s much too late now for anyone to save that technology either. However, if appscript has done anything of worth at all, it’s been to enlighten a small number of (relatively) traditional programmers with insights into the possibilities and benefits offered by a high-level, general-purpose IPC framework shaped by an enlightened UI-centric philosophy - something that AppleScript, SB and the AS team never managed to do. That makes you a rare resource - and one that could perhaps achieve better things than mope over what’s already lost.

You can’t save the AS/AE/AEOM platform, but if you can regroup on ASOC as a stopgap measure and enlighten enough other ObjC developers as to the merits of general-purpose IPC, there might just be a glimmer of hope you could salvage part of its vision. Even if you eventually end up having to roll up your sleeves (as I did) and build some of that post-AS future yourselves (hint: you could do worse than RESTful HTTP). And that’s all I have to say about that.

33. abarnert says:

I’ve verified that this does in fact break both AppleScript and ScriptingBridge over Remote Scripting. So maybe Apple will do something about it.

34. Greg says:

@all - I’m a little bit late to the appscript wake here, but I’m hoping someone can help me out.

I contribute code to an open source multi-platform project called ‘calibre’, an ebook manager written in python. I wrote a driver when the iPad was released allowing calibre to send ebooks to iTunes (and directly to the iPad) using py-appscript, then subsequently manipulate the ebook’s metadata. It worked well through iTunes 10.6.1. I understand from reading the above comments why it’s now broken, and the likelihood that even with a short-term patch, py-appscript won’t work very much longer.

My driver uses dozens of calls to iTunes to add, delete, update covers, and modify metadata. At this time it would be nice to just get things working again with 10.6.3+, and warn users that it’s a short-term fix. But I don’t have any idea what I would need to do in a python environment to emulate the patch described in post #19 and 30.

Can anyone help me understand what I would need to do to get appscript working with python and iTunes 10.6.3?

Thanks

35. Greg says:

Addendum: I did file a bug report with Apple when I first discovered that calibre was broken with iTunes 10.6.3, but nothing’s happened with it yet.

36. abarnert says:

Greg, you need to do one of two things:

1. On a machine with iTunes 10.6.1 or older, import appscript.terminology and do an “appscript.terminology.dump(‘/Applications/iTunes.app’, ‘itunes.py’)”. Then, in calibre, import itunes as well as appscript, and instead of doing “appscript.app(‘iTunes’)”, do “appscript.app(‘iTunes’, terms=itunes)”.

2. Look at what Matt did above for Ruby, scripting the sdef command line tool and converting the results into the form that the terms parameter takes, and do the same in Python.

The first one is much simpler, and works for remote scripting. The downside is that if Apple changes the scripting dictionary of iTunes (which they haven’t done in a long time, and haven’t done in a breaking way for even longer, but it could happen…), you’ll still be using the 10.6.1 dictionary.

37. Greg says:

@abarnet: Thanks for the quick response. I will try #1 and report back.

38. Greg says:

@abarnert (sorry for the typo earlier): I tried #1, and I get the following NotImplementedError: aem.ae.getappterminology isn’t available in 64-bit processes.

Am I out of luck?

39. abarnert says:

@Greg: Hmm… I thought that worked by using ‘gdte’, not by calling OSAGetAppTerminology. It looks like I tested it on a 32-bit Leopard system, just because that’s the first box I could find around here that didn’t have iTunes 10.6.3 on it…

Anyway, one workaround is to run Python in 32-bit mode. Unless you’ve installed manually and done something funky, Python and appscript ought to be universal builds, right?

40. abarnert says:

@Greg: I just tested on Lion 10.7.4, stock 64-bit /usr/bin/python, final version of appscript via easy_install (“appscript-1.0.0-py2.7-macosx-10.7-intel.egg”), and I can dump terminology just fine. (Of course I’ve got iTunes 10.6.3 on this machine, so I get an empty terminology module, but the same thing against, e.g., TextEdit works fine.) Any chance you’re using an older appscript version? (Or python3, or anything else different?)

41. abarnert says:

OK, it looks like appscript 0.22, v.718, 2012-12-09T22:30:37, changed what terminology.dump() uses. So, you probably have an older version.

Can you upgrade to appscript 1.0? If not, can you temporarily install appscript 1.0 on one machine with pre-10.6.3 iTunes just to run the dump? If you really need to make older appscript work, it looks like the terminology module already had everything it needed for a long time before 0.22, and it’s just a matter of calling aetesforapp(Application(apppath)) instead of ae.getappterminology(apppath) at terminology.py:206, so you could temporarily hack up your local copy, or copy and paste enough of terminology.py to hack together a working dump, or whatever.

42. Greg says:

I can try what you suggested, but I’m wondering if the fact that you have in fact generated the file that I need. If that’s the case, could you post it somewhere (or email it to me) so that I could move to the second step, testing it with 10.6.3?

I need to work with the primary developer of calibre to update the appscript version, which I can do, but I really want to figure out if the approach outlined in this thread is a solution for me.

43. Greg and abarnert,
I can appreciate you two not wanting to exchange email addresses out in public. If you both email me (my address is in the Meta section of the sidebar at the top of the page), I can send your addresses to each other.

This is not an attempt to stop you from commenting here, but it looks like some direct communication would make things run more smoothly.

44. Greg says:

@Dr. Drang: I sent you email, thanks for helping out.

45. Greg says:

@abarnert: I now have a build of calibre with the 1.0 version of appscript included, so I was able to generate the iTunes.py file locally.

46. Greg says:

@all: The static glue binding seems to work! Thanks for the assistance.

47. abarnert says:

Too late for Greg, but I gathered together the Ruby and Python terminology and a complete ASDictionary dump, including ObjC glue, from iTunes 10.6.1 and posted it at https://github.com/abarnert/itunesterms. I’d appreciate it if people could let me know if anything doesn’t work, if I’ve explained everything wrong, or if I’ve forgotten to attribute anyone for their work.

48. matt says:

Just to finish off my part of this conversation, I have posted the appscript codebase to github (because it’s easier to fork there) and have contributed a utility script to rb-appscript that fetches the dictionary directly, dynamically, using the sdef tool instead of ascr/gdte. This means there’s no need for a dumped glue file. Works fine for iTunes 10.6.3. Please see https://github.com/mattneub/appscript for more info.

Perhaps some kind Python-knowing soul would like to port this to Python for the py-appscript users out there. If so, just fork and request a pull.

Thanks to @drang for letting me play in his sandbox. Over and out.

49. Ray says:

For those looking for better string manipulation and list handling in AppleScript itself, I would highly recommend Shane Stanley’s free ASObjC Runner: http://www.macosxautomation.com/applescript/apps/runner_vanilla.html

I know some of you think AppleScript’s days are numbered. Its death has been predicted as many times as the death of Apple itself, with the difference being that no one is predicting the latter now.

I’m one of those AppleScript users with no programming background, and am aware of many others. The size of the group I can’t estimate, as most of these users seldom comment online in forums or mailing lists. Of course, I have no idea of the number of rb-appscript or py-appscript users either.

I’ll agree with what some have said about the decline of the print industry affecting AppleScript. But I also see some renewed interest in AppleScript as the Mac user base grows. So I’m not making any predictions. I just know there are still many companies out there continuing to quietly save boatloads of cash using AppleScript for automation.