 |
 |
|
|
|
|
|
|
AppleScript is remarkable for being perhaps the worst programming language in modern history that has managed nonetheless to reach a wide audience. This unlikely success can be attributed to the fact that application scripting is fantastically useful and, when it comes to application scripting on the Mac platform, AppleScript has always been pretty much the only game in town. All that is on the brink of changing, however, thanks to Hamish Sanderson's appscript project. Appscript allows you to do OS X application scripting with Python in a fairly natural, object-oriented fashion. For example, to get a list of the file locations for all photos in the current iPhoto album you can write this Python code: files = app("iPhoto.app").current_album.photos.image_path.get()
To find out what properties an album has you can write: app("iPhoto.app").current_album.help()
So why is this important? To be sure, it has been possible, if awkward, to do app scripting in Python for quite a while now using Another reason this matters is that OS X is increasingly attracting Linux users who have become tired of recompiling kernels and having flaky hardware support. These people have lots of experience scripting in various languages like Bash and Python. They're not likely to pick up AppleScript since it's such a crappy language and has no application besides OS X app scripting. If they can accomplish the same things in Python, however, then the floodgate opens for all sorts of cool hacks and scripts. As a demonstration of what I'm talking about, I offer iphoto2album, a script that takes the current iPhoto album and adds it to a photo album made by Album. It requires working installations of iPhoto, appscript, and album, of course. You'll probably need to tweak a couple of parameters at the top of the scripts, but there's nothing too tricky. Granted, this is probably too tricky for the average Mac user, but it's a start. Speaking of Linux to OS X converts, I was pinged recently by Titus Brown, who was one of the first folks I know to make the jump. He recently established a blog and appears to be updating it frequently, unlike myself. I'm lucky to push out one post a month — he seems to be doing them daily. If his first few posts are anything to go by, the blog should be titled “How to Win Friends and Influence People in the Bioinformatics Software Industry.” BTW, Titus is one of the few people I know who actually writes code as often as he talks about writing code, so he truly has a leg to stand on when he tells you your software sucks ass.
|
|
 |
 |
Thankfully, my code is generally too short to suck ass. It would have to suck ankle or kneecap or something.
i’m piping up because this page comes up when searching for “appscript”, which i think people may be doing as they hunt for context
i agree with your assessment of appscript — i’m very enthusiastic about it — but i’d like to offer a couple of counterpoints to the larger picture you paint; this is not to take away from appscript, but to add some appreciation for where it stands and how it can develop
i’m not sure what “niche” you refer to above, so i think it’s worth mentioning Frontier, which predated AppleScript, has a broader scope than AppleScript (all the interapp capabilities, much more built-in functionality, and later a complete TCP/IP suite & server); Frontier has had two periods, including the present, in which it was free (the core is now open-source at frontierkernel.sourceforge.net); i like Frontier’s no-nonsense syntax, object database and outliner editor; Python/appscript is the logical next step for Mac Frontier programmers, and while Python is of course much more sophisticated, i think it could still benefit from Frontier’s outliner IDE concept and approach to persistence
also while i agree that AppleScript as a language has major usability flaws, i sputtered a bit at “perhaps the worst” — it has a unique, dynamic and expressive (if subtle, contorted and ambiguous) OO design that is much more sophisticated than so called “OO” VB, for instance; one might also question how AppleScript might have developed if it really had ever reached a “wide audience”; AppleScript is only now reaching belated maturity, hunchback wizard that it is; still, Python + appscript will need more integration and support it can supplant AppleScript for sheer convenience
finally, as you seem to acknowledge, anyone who might make headway with appscript in its current state will really need some respect for and comfort with AppleScript; for appscript to develop into the core Mac OS X interapp tool it could become, i think a synergy will be needed, such as direct ways to address Python/appscript objects from AppleScript