On 3 Dec, 01:29, John J. [email protected]
After spending some time withAppleScriptfor a day or two now in my
spare time, let me assure you:
aversion is good.AppleScriptis an old dog and it shows. Limitations
There are a lot of powerful little hooks in it, but it’s hardly worth
the effort to reach the level of using them.
The AppleScript language is largely crud, but the one thing it does do
extremely well is speak Apple events to other applications. Other
languages have been appallingly slow to catch up in this area; as a
result, most of the application-specific domain knowledge still lies
over in the AppleScript community.
Therefore, if you want to do any significant amount of application
automation work in any language, then realistically you’ll need to get
at least a working understanding of AppleScript under your belt first.
(Yes it sucks; but if you ever want things to change then somebody’s
gotta go first.) Learning the language will enable you to grok
existing AppleScripts for hints and solutions and phrase questions in
terms that experienced AppleScripters - who may not know much about
general programming, but know these applications scripting interfaces
like the backs of their hands - can understand and reply to.
The best book for existing developers to get up to speed on
AppleScript is Matt N.'s ‘AppleScript: The Definitive Guide’
http://www.oreilly.com/catalog/applescpttdg2/. The language-specific
chapters you should be able to skim through; once you get past the
weird syntax, except for the Apple event stuff it’s a rather ordinary,
minimally-featured imperative scripting language. The chapters on
application scripting should contain information applicable to all
languages, though will be phrased in AppleScript terms, of course
(hence the need to know the language itself in order to make sense of
FWIW, Brian M. (‘Everyday Scripting with Ruby’) is also planning
to write a book on Mac automation with Ruby (http://www.exampler.com/
blog/2007/11/27/scripting-your-mac-with-ruby/) which will include
material on using Ruby in place of AppleScript, although I don’t
imagine it will be out until well into next year.
I’ve got enough now to where the only thing I have to figure out is
how to leverageApplescriptfor the GUI scripting of adding files to
the library. The concept is simple, but I’m working on the learning
the mechanism now.
I’m not an iTunes scripting guru, but I would think a fairly simple
sounding task like yours should be entirely doable via iTunes own
scripting interface. GUI Scripting is hackish and fragile, and best
avoided if at all possible.
Best place for asking application-specific questions would probably be
the AppleScript-users list (there are other places, but AS-users is
the most popular and contains a reasonable proportion of experienced
Curious folks, AppleScripters; they often seem to exist in a bubble
disconnected from the rest of the programming world, but are generally
eager to help. The quality of advice can vary, but I don’t think
that’s different to anywhere else.
Once you’ve found out the magic incantations to use - usually the
hardest part - you’ll need to translate them from AppleScript to Ruby
syntax yourself. First thing obviously is to print out the iTunes
dictionary in Ruby format using the tools supplied with the Apple
event bridge you’re using (e.g. for appscript use ASDictionary). If
you get stuck you can try posting them here - there’s a few folks like
myself who have some experience using Ruby as an AppleScript
replacement, that may be able to help. Another extremely handy tool is
ASTranslate, which converts AppleScript commands to their Ruby
appscript equivalents - while it’s not a full-blown code converter,
it’s a great tool for helping to work out how to rephrase individual