1 person found this helpful
Assuring fresh previews are available to a plugin is a challenge, and one that I've never solved perfectly.
That said, here are two ideas:
1. stuff the keyboard with preview-building keystrokes (all versions).
2. Use the new Lr method: photo:requestJpegThumbnail (Lr5 only, and subject to "limitations").
Warning: the new Lr5 method may or may not work. If user is in develop module it won't always work (although it may seem like it worked, it sometimes returns a big blank/white image instead of one with a proper image), and if Lr (UI) would go to generate preview itself, the request-jpeg-thumbnail method will time out and not supply a preview at all.
So, if you're serious, it will take some programming, and trying multiple things, and checking for...
You can download PreviewExporter and see some of the hoops I jumped through. Also, Gazoo uses (preferrably fresh) previews for doing auto black/white-point computations, and so you can see what I did there to attempt assurance that previews were fresh.
PS - If you only care that there is some kinda preview, which isn't necessarily fresh, the job gets easier...
PPS - ShowBiz v4 (never released) was built around requestJpegThumbnail for assuring fresh previews, but it proved so problematic that it was abandoned in favor of method #1 (see above), which is what got released in v5.
PPPS - If you only care about a true (small) thumbnail, and usually they'll be there, another option, albeit a tad tacky, is to select a photo if it's preview is missing, since Lr will build thumbnail preview for most-selected photo, regardless of module...
where is the documentation for photo:requestJpegThumbnail? i just did a Google search and the first result is THIS page (and the other pages aren't helpful)
In the SDK (html API reference), which you presumably have, no? (LrPhoto object...)
how old is the sdk 5? i'm still looking at sdk 4 which i downloaded like 2 months ago. i just downloaded sdk 5 but i doubt my version of lightroom supports it.
Well, if you're developing on Lr4, then I suppose there is no sense tempting yourself with Lr5 SDK, which is where the requestJpegThumbnails method was introduced. However, I recommend upgrading to Lr5, not only for the improvements to app, but also SDK. That said, a lot of the new methods in Lr5 SDK were not done well and come with caveats (like they only work if user is in a certain module but there is no way to determine nor impose which module user is in - yep: hard to believe, but true - reported during beta, but still not fixed........
Anyway, check out the above-mentioned plugins if you want to look at sample code.
i actually am running Lr5 -- for some reason i thought the SDK version numbers were not in sync (there's that word again) with the Lr version numbers (the most advanced SDK when i installed Lr5 was still SDK 4). of course, i have to also worry about the people who will be using my plugin. i can make it behave in a way that forces users with earlier versions to do more manual stuff in the Lr interface before using my plugin, but obviously the idea of using a plugin is to minimize that work. Ideally Adobe should provide an SDK equivalent for everything doable via the menus.
Well, as you know, the SDK proper (that which you download separately) is nothing more than documentation and sample plugins. In the case of Lr5, the SDK documentation was not released until around the time of Lr5.2. The functions were there, and whilst not officially supported yet, not much changed (nothing changed as far as I know in documented functions) between Lr5.0 & Lr5.2, except with the help of the documentation, we no longer had to guess what the parameters are. As you probably know, Adobe freezes (new) development as much as possible when a new (major) version is released, SDK (functions) included, whether they've gotten around to releasing the documentation yet or not.
PS - I whole-heartedly agree that if plugins were able to do anything on the menus, it would be a big step up, and actually plugins *can* do anything on a menu (if it has a keyboard accelerator assigned), via keyboard stuffing, although operation on Mac is spotty (executing text scripts via osascript interpreter works on some systems, but not others - dunno why, yet), it works reliably on Windows boxes (via auto-hotkey), subject to certain caveats, so OK: not entirely reliable on Windows either.
Reminder: things in the LrExportMenuItems list appear on the File menu - I think that's indicative that Adobe's biggest desire for plugins was to implement exporting / publishing. The "other fun things to do with plugins" stuff is secondary, or so I theorize. Certainly they haven't been giving it much attention in the code..
Anyway, there is no way around coding for the least common denominator, or version checking, if you need to make plugins run on a range of Lr versions.
Once upon a time, Eric Scouten (the original SDK "engineer") seemed to give a darn about the SDK, and was active in this forum... - those days seem gone, evidenced by recent SDK improvements being so feeble, and Chet Drarvik (who took over for Eric) keeps well hidden from plugin authors.
Are you familiar with this one?: