Posts Tagged lua
(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)
It’s 1:30am, I’ve been working on this for the last few hours (and got afair bit of stuf done), but i can’t wrap my head around this last problem.
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… 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.