On 1 Jan 2009, at 04:57, Scott Anguish wrote:
> heh, no. This is a personal project I'm messing with. Nothing work
> related.
Have fun. FWIW, a few tips to get you started:
- Despite the superficial appearance of AppleScript/appscript/SB/
etc.'s APIs, Apple event IPC does not operate according to object-
oriented rules (a very common misconception) - it's actually RPC
+queries, roughly analogous to using XPath over XML-RPC. There are
some aspects of the Apple Event Object Model that are derived from OO
(e.g. its tree-shaped structure), which is why even folks who think
it's OO manage to be somewhat functional in it; sooner or later though
the procedural and relational behaviours will drive you nuts if you
don't appreciate what's actually going on. Oddly, Apple's own
documentation never seems to explain this to users, which is probably
one of the reasons that so many programmers - especially those with a
strong OO background - end up hating AppleScript and Apple event IPC
so much.
- Following on from the above point, the reason that iTunes' selection
property holds a reference (query object), not a list, is that it
allows you to construct requests like this:
tell application "iTunes"
get name of selection
end tell
--> {"It's Oh So Quiet", "Enjoy", "Isobel", "Possibly Maybe", "I Miss
You"}
and this:
tell application "iTunes"
duplicate selection to playlist "user choice"
end tell
--> {file track id 56362 of user playlist id 56283 of source id 43 of
application "iTunes",
file track id 56363 of user playlist id 56283 of source id 43 of
application "iTunes", ...}
Note that neither of these examples will translate to SB (short of
doing everything with raw AE codes), though they work fine in appscript:
ITApplication *itunes = [ITApplication applicationWithName: @"iTunes"];
id names = [[[itunes selection] name] getList]; // will be nil if no
items selected (i.e. "Can't get <ref>" error)
NSLog(@"%@", names);
id newTracks = [[[[itunes selection] duplicate] to: [[itunes
playlists] byName: @"user choice"]] send];
NSLog(@"%@", newTracks);
- The ability of a single command to operate on multiple objects gets
pretty important when dealing with large playlists - the main
bottleneck being the time it takes iTunes to resolve each query (the
inter-process messaging isn't free either). Example:
#!/usr/bin/python
from time import time
from appscript import *
playlist = app('iTunes').playlists['stress test']
print playlist.count(each=k.track) # 40960 tracks
t = time()
names = []
for track in playlist.tracks():
names.append(track.name())
print time() - t # 39.9 sec
t = time()
names = playlist.tracks.name()
print time() - t # 1.3 sec
- Most applications' Apple event APIs are appallingly under-
documented, so most of the time you have to figure out what they can
and can't do via educated guesswork, scraping through third-party
scripts for tips and asking for advice on applescript-users. If you're
not already familiar with AppleScript then I'd recommend getting a
basic grasp on the beast - Matt Neuburg's 'AppleScript: The Definitive
Guide' provides the best programmer-friendly guide to the language
that I know of, and isn't shy of discussing the platform's many faults
as well as its benefits. The current edition (2nd) doesn't cover the
changes in 10.5, but I believe Matt has an errata section on his
website. Oh, and there's also a couple of very enlightening papers by
Dr William Cook discussing AppleScript's original philosophy and
design that should help to make sense of a lot of the weirdness - you
can find them via the appscript site's links page.
HTH
has
--
Control AppleScriptable applications from Python, Ruby and ObjC:
http://appscript.sourceforge.net
