Logfiles grow over time if you don't manage them, but Lightroom doesn't provide a way to automatically delete the generated logfiles. We could manage the log ourselves, but we can't tell Lightroom to log to a particular file.
We know that the log is always created in the user's documents folder. Thus, we can use LrPathUtils.getStandardFilePath('documents') to get a path to that folder. We also know the name of the file and the extension, so we can build a full filepath that we can use to manage the logfile.
ExifTool entails a substantial overhead loading and initializing. If this is done every image, processing can be considerably slower.
The solution I have employed is to load exiftool only once with the -stay_open option, then continue to issue -execute commands and read results from pipe asynchronously. The code below is for example purposes only, the latest version can be found at: https://www.assembla.com/spaces/lrdevplugin/
Sometimes a plugin could benefit from creating virtual copies, but its not directly supported by SDK3
Judicious use of keyboard stuffing to inject Ctrl/Cmd-'
Both the Lightroom 2 and 3 SDKs allow a developer to run code when a plugin is executed, but the features don't always run when developers would expect them to e.g. code can be triggered when the plugin is disabled or not run when Lightroom starts.
Using an empty metadata tagset and other SDK features we can force code to run for enabled plugins immediately after they become active, regardless of whether that was due to Lightroom starting or direct user intervention.
If your plugin attempts to access the catalog for writing while its already being accessed by another plugin for writing, there will be an error in your plugin. And, since you cant control what other plugins may be accessing the catalog for writing when your plugin attempts to access it, it pays to have some means of contending, to improve odds for success, and a better error message upon failure.
The general technique I recommend is to use a similar scheme for arbitration that is used to resolve ethernet contention: Back off by a random amount, then try again. This relies on the ability to determine the difference between a catalog-unavailable error and a target catalog function error.
This site is produced in partnership with O'Reilly.