There are currently a lot of Mac users of Lightroom who are counting down the hours until Adobe releases a fix to get Lightroom working properly on Apple’s latest operating system, Leopard. From the recent announcements made, it sounds as though Adobe has started work on a release (1.2.1?) to overcome these Leopard shortcomings as soon as possible — mostly likely the next couple weeks.
As a Lightroom user that still has a fully functional application, there is currently one feature — that’s admittedly not trivial — that I’m counting down the days to: the ability to extend and customize Lightroom to suit my needs via scripting. Why do I find this a pressing issue right now? I’ve spent time over the last few days throwing together some JavaScript to automate some oft–repeated and mundane tasks in Photoshop (yes, that little language is at home in the mother of image editing applications and web browsers), and have again come to appreciate the utility of having scripting hooks in your workflow’s tools. That could also just be the computer programmer inside of me speaking.
But it’s not a matter of if scripting will be supported in a future version of Lightroom, it’s a matter of when, as Mark Hamburg — Lightroom’s chief — has mused about the subject before. However, as mentioned in the interview, knowledge of JavaScript won’t get you very far when it comes to Lightroom’s scripting support. Why?
Adobe’s staple applications (such as Photoshop & Illustrator, and the recent additions to the family such as Flash & Dreamweaver from the Macromedia acquisition) share a common look and feel: concepts such as palettes, workspaces, and generally speaking, the whole application interface look more–or–less the same from one environment to the next. And there’s a good reason for that: they share a common library of code that takes care of the heavy lifting common to all of the applications. The foundations of the application’s scripting engine could be considered as part of this toolkit; Photoshop, Illustrator, and others support a variety of scripting languages: JavaScript (supported on both Mac and Windows), AppleScript (only on the Mac), and Visual Basic (only on Windows).
However, Lightroom follows a different path; its interface & application logic is built using an embedded programming language called Lua, rather than using Adobe’s existing toolkit & libraries (which explains a lot regarding why Lightroom looks and behaves so differently from its cousins in the Creative Suite). Those who have cobbled together enough JavaScript to automate other Adobe applications (or just about any web browser) would do well to start brushing up on Lua in preparation for the introduction of scripting support in Lightroom (whenever that happens to be). The good news is that a strong grasp on the fundamentals of JavaScript (or any other scripting or “full-fledged programming” language, for that matter) will definitely go a long way when adding a new language to your toolbelt.
Without dismissing the value of cross platform scripting, I'd argue that it's a nicety for vast numbers of users. Many Mac scripters never work with PCs, and vice versa. While I like Photoshop's AS+JS+VB model, most scripting tasks there are for automation and efficiency *within* the application. The AS+VB added little value.
But a lot of those multi image processing efficiencies are what Lightroom is all about, and its scripting requirements are going to involve much more interaction than Photoshop with external applications and systems. I don't just mean so called "creative" products. An obvious area is bringing in metadata from legacy DAM systems - eg scripting metadata from Filemaker/Access. Another might be sending details of a job to your Word invoice template, or to a full scale accounting and costing system. One might use Word to spellcheck a planned submission to a picture library, or you might record job details in a contact manager or a Windows-based CRM so you can easily cross reference customers and orders.
A workflow database like Lightroom suits such wider business automation and it's not a downfall at all that a script only runs on a single platform.
John (middle name David),
Anyone who scripts Photoshop with AppleScript is signing themselves up for a world of pain: AppleScript may be marketed as "powerful and versatile" language, but in reality the syntax is confusing, and most successful scripts that are anything more than a few lines long are a result of hours of trial and error. I dabbled in Visual Basic programming years ago, but have never used it to script other applications; I do recall it being a little more structured and logical than AppleScript.
While it may be convenient to be able to script Photoshop in your platform's "native" scripting language, there is one *huge* downfall to choosing AppleScript or Visual Basic: your scripts won't run on the other platform. By choosing to script Photoshop in JavaScript, you are ensuring that your work will be usable by both Windows and Macintosh versions of the application. That fact alone is reason enough to not consider the native options.
And there's something to be said for having scripting support with the natural language of choice *now* (or, in the near future, as the case may be) rather than support for 3 different languages further on down the road. The flip side of that coin, of course, is that choice is never a bad thing.
However, after looking over Lua's documentation and stumbling across a few examples scattered across the web, anyone that has taken the time to teach themselves a scripting language will pick up Lua's quirks (vis-a-vis JavaScript) in very little time.
(And Objective-C *does* seem pretty conducive to being scripted; that's what makes adding basic AppleScript support in OS X applications relatively painless.)
I guess the moral of the story is: everything has tradeoffs :).
David Miller
Agree with David Mantripp here. The program's underlying architecture may prejudice the choice of scripting language it eventually offers, but that's not what would best serve the end user. User needs are what must determine the scripting offer, not the convenience of Lua's similarity to developer-level languages. It's where Photoshop got it right - two platform-specific languages with well-established and user friend IDE's, plus one language that's cross platform.
Hey guys,
Sorry for taking so long to chime in, as I've been away from my computer for a little while. Daveed echoes my point precisely, sorry if I didn't make it clear in my post!
Yet Another Dave :)
To David Mantripp:
You're right that for many apps the scripting language is decided somewhat independently from the languages that implement the app. However, that's primarily because the app is implemented in a language like C, C++, or Objective-C, which don't work really well for scripting. Lightroom is somewhat unique as a large off-the-shelf app in that it is already implemented using a language that fits the bill as a "scripting language" (Lua). (It also uses C and C++ for its database and image processing, respectively, but the app's logic -- including the UI and the code that drives the database and image processing -- are reportedly all Lua). So it makes a lot of sense to stick to Lua for 3rd party scripting. (Lua is also interesting because it embeds well in C and C++.)
I don't get the point here. Photoshop, ASFAIK, is not written in Javascript. I don't see what the language used to create the application has to do with the language chosen to script it. Otherwise I'm at a loss to understand how AppleScript exists...