Why are some fields overlapping and other not?  It seems to me that the Raw command should be all inclusive and the Formatted be only those fields that people commonly need and want to have pre-formatted. I've wondered the same thing -- just seems like suboptimal design. Also, note that passing "nil" does not retrieve all the fields, contrary to the documentation. You need to pass an explicit list to be sure to get the fields you want. ... View more

See this post for the speed of catalog:getRawMetadata() in LR 3.3: http://forums.adobe.com/thread/789680 ... View more

Have you ever seen them returned when you explicitly request them? Yes, I believe every documented field is returned by batchGetRawMetadata() and bachGetFormattedMetadata() when you pass it explicitly. LR 3.0 had a bug that would raise an error if you passed some of the documented fields, but it was silently fixed somewhere between 3.0 and 3.3 (no announcement in the release notes). ... View more

I think the working rule is to pass the list of all the fields you expect to get back. ... View more

getRawMetadata will return the whole set, as documented. That doesn't seem to be true in my tests -- catalog:batchGetRawMetadata (photos, nil) doesn't appear to return the following: countStackInFolderMembers, countVirtualCopies, durationInSeconds, isInStackInFolder, isVirtualCopy, keywords, masterPhoto, stackInFolderIsCollapsed, stackInFolderMembers, stackPositionInFolder, topOfStackInFolderContainingPhoto, virtualCopies It may be that batchGetRawMetadata (nil) will return some of these fields if they have non-default values, but at least for the stack-releated fields, they never get returned by batchGetRawMetadata (nil), even if a photo is in a stack. With catalog:batchGetFormattedMetadata (photos, nil), I've found just one field that isn't returned: folderName ... View more

I'm not planning on doing any more work until if/when the bug and limitation are fixed.  If get/setActiveSources can't replicate user actions (e.g. knowing that the current source is set to the previous import), then it's much less useful to me. ... View more

I was interested in something related: The ability to undo and redo source and filter selections.  A background task would capture the current state of sources and filters every second, for use by the Undo and Redo commands.  My unfinished prototype works well, except for the fact that getActiveSources() doesn't capture all the sources. ... View more

I read that a couple of months ago and wondered the same thing.  But I never got around to testing the actual semantics, because getActiveSources() is broken: http://forums.adobe.com/message/3302290#3302290 Also, it's undocumented that you need to call setActiveSources() from within a task: http://forums.adobe.com/message/3302389#3302389 ... View more

I wonder if it would be possible to write a true debug module for an IDE, hmmm... I think it would be very impractical, given that Adobe disabled most of the functions of the "debug" module (e.g. debug.sethook, debug.getlocal, etc.). I briefly considered a debugger implementation that would parse the Lua source and rewrite it with "hook calls" into a debugger API. I got as far as finding a Lua parser (in Lua) before deciding that would take much, much longer than I was willing to invest. If Adobe were to enable the full "debug" functionality, then a full debugger would be much more practical. ... View more

Maybe the small lrplugin community should start a wiki to catalog all these... Rob has already started that Wiki: http://www.assembla.com/wiki/show/lrdevplugin Much of that site is devoted to the particular framework he's developing, but there are also places to record plugin knowledge independent of the framework. ... View more

This doesn't:          searchDesc = {               {                   criteria = "captureTime",                   operation = "=",                   value = "2010-11-28",               }, In fact, I can't find any solution that a "=" criteria works for captureTime. One issue here is that the operation is "==", not "=".  If you change it to "==", you should get all photos whose capture date is the one specified. I've found that the documentation for findPhotos() is incomplete.  A good way to understand the syntax of "searchDesc" is to create a Smart Collection in the user interface, select and right-click it, and do Export Smart Collection Settings.  This will create a ".lrsmcol" file containing the "searchDesc" that you can edit in a text editor. Another issue is that findPhotos() does indeed seem to operate only on dates, not date/times.  If you really need to specicify a time, I think Rob's solution is the only one. ... View more

Here's the idiom: local Info = require "Info" ...Info.VERSION... ... View more

I second those ideas -- having a standard method of installation would certainly make it easier for both users and developers. ... View more

I noticed the yield issue as well.  But it's only problematic on Windows Yeah, I measured the cost of LrTasks.yield() on Mac to be about 1/100 to 1/1000 of that on Windows.   And I noticed that a number of API functions, e.g. the keyword-accessing functions, went proportionally faster on Mac as well. ... View more

You might consider profiling your plugins using the function Debug.profileFunc() from my debugging toolkit (free, of course): http://www.johnrellis.com/lightroom/debugging-toolkit.htm This is an elapsed-time profiler, which is generally more useful than a CPU-time profiler.   Because it imposes a non-trivial overhead on each profiled function, start profiling higher-level functions and then drill down into the bigger hogs. One thing I've found is that a number of the SDK API functions appear to call LrTasks.yield() (or equivalent), and this seems to impose a minimum overhead of at least 10 - 20 ms.   Doesn't seem like much until you discover you're calling it hundreds or thousands of times. ... View more

Based on my (very) light reading about the Lua implementation, I'd guess that Lua string operations are roughly the same cost as Java string operations. There are two components to the cost: doing the byte manipulations, and the amortized cost of garbage-collecting the strings later.  Unlike Java, Lua needs to hash each string into a global string table, but the incremental cost of that is likely smaller than you think for many apps, since tests for equality take a single instruction, and the hashing can reduce additional storage allocations.   Also, I'd guess that the Lua garbage collector is not as efficient as a modern Java GC, but that's just an educated guess. ... View more

Unfortunately, the SDK does not provide methods for creating catalogs or deleting photos from catalogs; unlike other scriptable applications, such as Microsoft Office, there are many, many functions that users can perform that aren't covered by the scripting APIs. A workaround is to send keystrokes to LR using tools like Autohotkey on Windows or Applescript on Mac.  See Rob Cole's plugin framework for details: http://www.assembla.com/wiki/show/lrdevplugin ... View more

Interesting gratuitous difference between LR Mac and Windows. ... View more

I think LR will anyway delete the catalog entry which would just make the raw file orphaned. If you want to protect files, I guess you have to implement a publish service, like in Jeff Friedl's plugin. It appears that if LR can't move the photo to the Recycle Bin, then it doesn't get removed from the catalog.  I verified that by denying the permissions Write Attributes and Write Extended Attributes in Windows Explorer and then trying to remove the photo from the catalog. ... View more

Notta one Lua programmer hasn't made that mistake before - its part of the price of admission: welcome to the club! What makes the "dot instead of colon" error so frustrating is that the error message, "assertion failed", is so uninformative.  Adobe could save its SDK customers countless hours of frustration simply by making the error message more informative. ... View more

I haven't provided tooltips on my plugins, so I don't have any long-term experience.  I modified one to have tooltips on an "edit_field" and a "static_text", and the tooltip consistently appeared across about 6 invocations and lots of clicking around, changing window focus, etc.  Not exactly strong evidence either way. ... View more

One thing to check is that the window has focus -- in general on Windows, tooltips only display when a window has focus, and that seems to be true of the SDK as well.  On Windows Vista and 7, the default "aero" user interface doesn't make it that easy to tell whether a window has focus. ... View more

Hmm, it also doesn't protect deletion or moving to the Recycle Bin by Windows Explorer. I've never bothered to really understand Windows permissions (which I relearn to regret every few years). But some experimentation suggests you'll have to to remove or deny the Write Attributes and Write Extended Attributes permissions using "icacls" to prevent Windows Explorer and LR from deleting or moving a file to the Recycle Bin. But perhaps someone has a more authoritative answer... ... View more

Last summer I read through the relevant section of the SDK Gude a few times, and I must admit I didn't fully grok what I would have to do with schema version numbers and updates.  So I've kept my head in the sand -- any clarity we could glean from others would be great. ... View more

Lightroom uses the industry-standard metadata field XMP:Rating to store rating.  So if you set that field from another program, LR will read it. As Pete indicated, LR does not read or write a photo's flags to its metadata.  Further, the LR SDK does not allow plugins to set the flags of a photo.  So there's no direct way to set the flags outside of LR and get them back into the catalog. ... View more

Very neat.  I'll be interested to learn your experience in how this works out in your plugins. In the past, in different contexts, my experience with keystroke stuffing (on Windows) was that it was "fragile".  I've thought a bit, and here are some of the issues I've encountered in the past: It's hard to handle dynamic application behavior.  A simple example is LR's Library menu -- when a non-folder source is selected, there is one menu command (Plug-in Extras) with S shortcut key, but when a folder source is selected, there are two (Plug-in Extras, Synchronize Folders), and thus the keystrokes needed to invoke Plug-in Extras vary depending on the LR source.  Since I rarely use folders as sources in LR (my workflow is not folder-based), I didn't even see this behavior until an Any File user point it out to me.  In general, the developer of a plugin using keystroke stuffing would have to carefully test it out in all the different LR contexts in which the plugin might be invoked). More complicated behavior, such as confirmation dialog boxes that only appear based on selection or application state, can be more problematic. Manipulating dialog boxes has been troublesome for the utilities I've used.  They typically have some facility for waiting until a dialog box appears, and then resuming the keystroke stuffing.   But if the application doesn't use the standard Windows toolkits (and at least some Adobe applications don't), the utilities may not be able to find the dialog box by name.  So then you have to program in a delay in your macro.  If you make the delay too short, the macro will fail.  If you make it too long, the user has to wait.  And if the user starts typing during the middle of the macro execution, you'll get unpredictable results. A lot of apps don't follow the Windows conventions and don't fully implement the standard tab, cursor key, and enter semantics (again, I've experienced that with Adobe apps).  While the utilities allow you to use relative mouse coordinates to "move" the mouse and make mouse clicks, that's incredibly fragile, since the app window could have different layout each time it's invoked. Despite all this, I've used keystroke macros to automate routine tasks in Photoshop Elements Editor (which disabled the action recording of full Photoshop) and Photosohop Elements Organizer.   But they were not entirely reliable.  But it may very well be that the uses you're envisioning for LR plugins will be straightforward and robust enough. ... View more

I don't know of any way of setting the flags, but perhaps someone else does.  (You can query them with catalog:findPhotos().) ... View more