Posts Tagged lightroom
(Note: This is a copy of my article on Adobe’s Lightroom Developer Connection. Just in case anything happens to it.)
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.
Using a logfile for logging a plugin is a simple way for tracing errors during development (arguably simpler than getting a console set up), and it’s simple for end users to send to you when reporting bugs.
However, Lightroom will constantly append to a logfile, so entries will get stale, and the file will grow as your plugin is used. So, we need to manage the logfile somehow.
The easiest solution is to simply delete any existing logfile on every (re)load of your plugin. The kink in this plan is that there is no way (at least, not documented in the API reference) to tell Lightroom to log to a specific file.
However, we know that Lightroom will create a log in the user’s Documents folder, and use the logger name for the filename, and use the file suffix “.log”. With this information, we can build a path using LrPathUtils functions that allows us to get a proper filepath, one that can be passed to LrFileUtils.delete().
Now that we have a path to the log, we can do whatever we want with it. It’s a simple matter to add code that will delete the logfile in your plugin initialization script.
As an example, this is what I’m currently using in my plugin:
01 local logger = import 'LrLogger'( 'Stash' )
02 local LrFileUtils = import 'LrFileUtils'
03 local LrPathUtils = import 'LrPathUtils'
05 local logPath = LrPathUtils.child(LrPathUtils.getStandardFilePath('documents'), "Stash.log")
06 if LrFileUtils.exists( logPath ) then
07 local success, reason = LrFileUtils.delete( logPath )
08 if not success then
09 logger:error("Error deleting existing logfile!" .. reason)
(If you want, you can see the code in context of the full plugin here: github.com/kyl191/lr-stash/blob/master/LrInitPlugin.lua)
Because I’ve encountered some problems, and found ways around them, but never documented them. I’m doing that now. Read the rest of this entry »
I’m adding stuff to my Sta.sh plugin for Lightroom, just because I can. (And while I wait for the Sta.sh API to stabilize.)
- Auto-updating to the latest version
- Debug logging & submission of logs
- Usage tracking
- New Sta.sh API features (Like folder renaming, except it’s broken as of when I write this post.)
So for the auto-update stuff, I was looking for some documentation of just how to get a check-box to show up in the plugin manager, so I can give the user the option of auto-updates.
Haven’t found it yet – what little I’ve found says I should have a file named “PluginManager.lua”, which there seems to be no documentation of on Adobe’s site (or anywhere else, annoyingly.), and the only reference I’ve found is code.google.com/p/gallerysync/source/browse/trunk/GallerySync.lrdevplugin/InfoProvider.lua?r=2 . Oh hey, most of it’s in the SDK Guide, not in the sample code
But what I did find was www.assembla.com/spaces/lrdevplugin/wiki – which seems to be a collection of notes on Lightroom plugin creation, as well as an interesting development setups. (And a plugin framework, just for good measure – but if I want to use it is another question altogether.)
The dev environment in question is this one: www.assembla.com/spaces/lrdevplugin/wiki/%28Mac-Win%29_IntelliJ_and_LUA
I couldn’t be bothered to download and compile the Lua source, so I just used the LuaforWindows binary from here: (Not using the newly released 5.2.0, because I’m not sure Lightroom would accept it.)
And because I use GitHub, not SVN, the build.xml file that was provided had to be modified. to use Git. I found an answer in a relevant StackOverflow question to use instead of the SVN revision code as specified. (Grab my revisions from github here.)
However, Ant needs the Java SDK to run – which I didn’t have, so off to download that too.
Once downloaded and installed, Ant still failed with “JDK not found”. I had to add the JDK to the project, then select it in the Ant Build panel, and only then did it run successfully.
So, I’ve been looking through the OAuth RFC, and this actually looks doable, with copious amounts of code from the Flickr plugin bundled with the Lightroom SDK.
The key thing is OAuth2 – It looks a lot simpler than OAuth1. Whereas OAuth1 needed messages to be signed, OAuth2 just throws stuff back and forth in the URL query string, and a smattering of JSON solely for the authorization token.
- Hard code stuff first (size, etc.) then gradually create the UI & allowing specific things to be set. (Mainly, size & quality of the rendered jpg.)
Use Resource owner password credentials, where the user will enter the username/password combination. The Facebook plugin tried the ‘standard’ OAuth thing (user logs in, confirms they allow the app, server issues a particular token to the app), but the plugin fell over at the “issuing to app’ bit. Link would open in Lightroom, but it wouldn’t authenticate.Never mind, dA only seems to want the response_type=code bit, and only type=code. type=token just fails silently. Now I’ll need to mock up a webpage to display the code. =|
- Instead of doing the placebo call, I’ll just try and grab the user’s dA symbol instead, and display that. Though, on second thought, I should probably do the placebo call and stick it in a function so I can call it before uploading a photo just to check that the token still works. Leave the dA symbol bit though.
So… Since my dedup program has… kinda stalled while I try to figure out how to implement the actual identifying and displaying duplicate files, I’m looking at other things to do. I finally got back to dA recently, and discovered they opened a new upload/file storage thing called sta.sh. Interestingly enough,the announcement had a developers section, and as I thought, it’s got a public API.
Now, for my pictures, I tend to (well, as of this post, always) upload my pictures to dA. So a publish thing in Lightroom would be nifty, and might have some use for other people. Though I’m a bit iffy about usefulness, because you can also upload via FTP to sta.sh. Which would be a whole lot easier than custom plugins and the like, so I don’t think anything will come of it.
That said, resources I found:
www.deviantart.com/developers/stash – the Sta.sh API docs
www.deviantart.com/developers/oauth2 – dA’s OAuth2 API docs
www.adobe.com/devnet/photoshoplightroom.html – Lightroom SDK
github.com/ignacio/LuaOAuth – OAuth in Lua. Despite no mention of OAuth2, there’s a interestingly named ‘OAuth2.lua’ file.
regex.info/blog/lua/json – JSON in Lua
w3.impa.br/~diego/software/luasocket/ – LuaSocket – HTTP requests and whatnot
www.inf.puc-rio.br/~brunoos/luasec/reference.html – LuaSec – does https support
Though, the Lightroom API reference says “Sends or retrieves data using HTTP or HTTPS POST.”, so hopefully the above 2 files can be ignored.
In theory, that’s all that’s needed. Rip out the guts of one of the development plugins (most likely the FTP plugin), sprinkle the OAuth2 stuff here and there as necessary, with JSON for garnish, and it should work.
Emphasis on should.
Nothing ever works as expected.