Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Exit
John R Ellis
LEGEND
John R Ellis
LEGEND
Activity
‎Jul 15, 2010
02:23 AM
A different solution: In the plugin's global environment, define a global variable "sentinel" whose value is a dummy table: sentinel = {value = "dummy table"} In the background task, create a Lua weak table that references the value of "sentinel". The background task periodically checks the value of the weak reference, and if it is nil, then you know the that the dummy table has been garbage collected, indicating that the global environment of the plugin has gonne away, indicating the plugin has been reloaded. A potential problem with this solution: You don't know when the garbage collector will actually run. It may be that in practice, it runs very frequently, but I don't know that.
... View more
‎Jul 15, 2010
02:08 AM
A hack workaround: When the persistent background task first starts, it writes the current time into a temp file and remembers that time. It reads the contents of the file every n seconds, and if it changes, it exits.
... View more
‎Jul 15, 2010
01:50 AM
In terms of performance, you'll most likely get the best performance reading in chunks much smaller than 100 MB, e.g. 1 MB or even smaller. You might see severely degraded performance trying to read an entire 500 MB file into memory. In terms of programming convenience, of course, it's nice to read an entire file all at once into a string.
... View more
‎Jul 09, 2010
03:04 PM
Yeah, there are many advantages to a dynamic language like Lua, but a big disadvantage is that pretty much any string of garbage can be executed, which makes PUI (programming under the influence) dangerous 😞
... View more
‎Jul 09, 2010
08:33 AM
To build on John's reply, double-check that the metadata definition declares the field browsable and searchable, e.g. metadataFieldsForPhotos = { {id = 'type', title = "Type", dataType = 'string', browsable = true, searchable = true},
... View more
‎Jul 08, 2010
08:18 PM
Jeff, thanks for the details -- all makes sense. I too am hoping that Adobe will invest in the performance of the SDK APIs. Even doing simple things like enumerating all the keywords takes two orders of magnitude too long.
... View more
‎Jul 08, 2010
12:01 PM
I have around 15k images and it takes only about 5 seconds to run this task on all images. That's much better performance than I've observed, so perhaps you could help me understand how to do better? Is that 5 seconds to run an incremental update, verifying that the shadow and actual values are identical? Does it also take 5 seconds to set the initial value of the shadow field, or does that take much longer? I assume you're calling the batch operations to get the metadata values? In my tests, batchGetRawMetadata() and batchGetFormattedMetadata() can do about 700 photos/sec on dateTimeOriginal, while you're oberving about 3000 photos/second. My computer is a little slow (dual-core 1.9 GHz, 4 GB memory, 7200 RPM disk, Windows 7 32-bit), but that shouldn't account for a 4x difference. Perhaps batchGetRawMetadata ("path") is reading from LR's in-memory data structures, while batchGetRawMetadata ("dateTimeOriginal") is doing a SQL query to the database?
... View more
‎Jul 08, 2010
09:51 AM
I have a couple of plugins that get and set view filters using catalog:getCurrentViewFilter() and setViewFilter(). You can reverse engineer the undocumented details (especially for the column browser) by saving filter presets and looking at their definitions in C:\Users\user\AppData\Roaming\Adobe\Lightroom\Filter Presets. It all seems to work pretty well. Sometimes however, the column browser doesn't appear to update itself properly when you set a view filter with multiple columns and multiple items selected -- but the filter appears to work correctly and show the right photos. I haven't discovered any mechanism to define new column types (e.g. process verson). The workaround of adding a plugin metadata field and then filtering on that is slow when you want to filter a large number of photos -- my tests indicate Lightroom can only set plugin metadata at the rate of a hundred or so photos a second.
... View more
‎Jul 07, 2010
02:56 PM
It seems like a basic design misfeature in the catalog (independent of the SDK), and it's biting users, as evidenced by the posts in the parent forum. I believe both Mac (by default) and Windows (always) ignore case when comparing paths. To cope, I guess we need to pretend that the following invariants are true: - The path recorded in the catalog has the same case as recorded in the file system. - Users and other tools won't change the case of paths by renaming a file. - The OS always reports the same case for a path (not true in Windows for network shares). Then, to accept as input paths from other tools or directly typed by users that may have case different than what's in the catalog, there should be a utility function that takes the path of an existing file and normalizes it to the case currently recorded in the file system. Looking at LrFileUtils, there's a slow way of doing that, using directoryEntries() to normalize the case of directories in the path starting at the root; but that will require platform-dependent parsing of the path components. Absent such a utility function, a plugin should never accept paths input by the user or another tool except via LrDialogs.runOpenPanel().
... View more
‎Jul 07, 2010
01:44 PM
The methods catalog:addPhoto () and catalog:findPhotoByPath () don't ignore case on WIndows 7 32-bit. If you invoke catalog:addPhoto () twice on the same path but using different case, LR 3 gets very confused, importing the photo a second time and adding a second C hierarchy to the Folders panel: In the parent forum, there are a number of posts observing that LR has added duplicated drive or folder entries, and some of them mention that the folders have different case. Here's code illustrating the problem. Beware that this could corrupt the catalog, so invoke it in a test catalog only: local LrDialogs = import 'LrDialogs' local LrTasks = import 'LrTasks' local catalog = import 'LrApplication'.activeCatalog () LrTasks.startAsyncTask (function () catalog:withWriteAccessDo ("Test add photo", function (context) local path = [ ] local photo = catalog:addPhoto (path) LrDialogs.message ("Path: " .. photo:getRawMetadata ("path")) LrDialogs.message ("Found by original case: " .. tostring (catalog:findPhotoByPath (path))) LrDialogs.message ("Found by lower case: " .. tostring (catalog:findPhotoByPath (string.lower (path)))) local photo = catalog:addPhoto (string.lower (path)) LrDialogs.message ("Path: " .. photo:getRawMetadata ("path")) end) end)
... View more
‎Jul 07, 2010
01:34 PM
Hmm, the combo boxes in DevAdjust don't work on my config. Here's what I did: 1. File > Plug-in Extras > DevAdjust 2. Adjustments | New Presets | Combos 3. In the first combo box, type "Tone Curve - Darks", enter 5.00 as the value 4. Save As Preset, use the filename "Test1" 5. Examine the contents of Test1.lua -- it's empty. 6. Repeat, but instead of typing, use the drop-down to select "Tone Curve - Darks". 7. The contents of Test1.lua are no longer empty. I'm stuck. I wonder if this is specific to my config or to Windows 7 32-bit? Anyone else with Windows 7 32-bit who could run the simple test code above?
... View more
‎Jul 07, 2010
10:50 AM
Probably you need to bind the value to a property instead of specifying a fixed value. Hmm, here's a version binding to a property, and it still doesnt work: local LrBinding = import 'LrBinding' local LrDialogs = import 'LrDialogs' local LrFunctionContext = import 'LrFunctionContext' local LrView = import 'LrView' local f = LrView.osFactory() LrFunctionContext.callWithContext ("test", function (context) local prop = LrBinding.makePropertyTable (context) LrDialogs.presentModalDialog {title = "Test", contents = f:combo_box {bind_to_object = prop, value = LrView.bind ("value"), items = {"1", "2", "3"}}} LrDialogs.message (prop.value) end) When you select an item from the menu, that gets displayed in the message dialog, but any value you type in isn't. I'm not having any such problems. I wonder what's different. Does the code above work on your machine? Which platform? I'm on Windows 7 32-bit. Note that the example on page 101 of the SDK Guide doesn't work for me either. Does one of your published plugins use combo boxes within presentModalDialog ()? If so, I could download it and see if it works properly on my config.
... View more
‎Jul 07, 2010
12:36 AM
See also http://forums.adobe.com/thread/675142.
... View more
‎Jul 07, 2010
12:34 AM
It appears that combo boxes don't work at all, ignoring any input the user types: local LrDialogs = import 'LrDialogs' local LrView = import 'LrView' local f = LrView.osFactory() local combo = f:combo_box {value = 1, items = {1, 2, 3}} LrDialogs.presentModalDialog {title = "Test", contents = combo} LrDialogs.message (combo.value) Am I missing something obvious? I tried the example in the SDK Guide on page 101, and that doesn't seem to work either. This would explain why validation of combo boxes doesn't work: http://forums.adobe.com/thread/673170?tstart=0
... View more
‎Jul 06, 2010
04:37 PM
1 Upvote
I haven't found any documented method for adding controls to a dialog that's being displayed. But there are techniques you could use to solve your problem: 1. After you get the data and know how many controls you need, close the first dialog and open a second one with the right number of controls. 2. Create the maximum number of controls, setting .visible = false to hide them. Unhide as many as necessary after you've received the data.
... View more
‎Jul 04, 2010
02:33 PM
In SDK 3.0, a numeric edit_field control can easily get into an infinite loop of popping up an "Invalid numeric entry" message, and the user is forced to kill LR using the task manager. To reproduce: 1. Run the test plugin below. 2. Click in another (non-Lightroom) window. Depending on the arrangement of windows, the "Invalid numeric entry" message pops up below the main LR window, invisible to the user. 3. Click back in the edit_field of the plugin. At this point, the "Invalid numeric entry" message is visible, and clicking OK just brings it up again. You've got to use the task manager to kill Lightroom. The plugin code: local LrDialogs = import 'LrDialogs' local f = import 'LrView'.osFactory() LrDialogs.presentModalDialog { title = "Test", contents = f:edit_field {min = 1}} I've submitted this via the Web form but posted it here in case others encounter similar symptoms.
... View more
‎Jul 03, 2010
01:06 PM
Combo boxes don't support the min, max, precision, or validate properties, contrary to what the documentation states in "Lightroom SDK 3.0\API Reference\modules\LrView edit view properties.html". Here's a test program that shows the problems: local LrDialogs = import 'LrDialogs' local LrView = import 'LrView' local f = LrView.osFactory() local text = f:static_text {} local function validate (view, value) text.title = "validate called from " .. view.label return true, value, nil end LrDialogs.presentModalDialog { title = "Test", contents = f:column { text, f:row { f:static_text {title = "numeric:"}, f:edit_field {min = 1, max = 10, precision = 0}}, f:row { f:static_text {title = "numeric:"}, f:combo_box {min = 1, max = 10, precision = 0, items = {1, 2, 3}}}, f:row { f:static_text {title = "validate:"}, f:edit_field {validate = validate, label = "edit_field"}}, f:row { f:static_text {title = "validate:"}, f:combo_box {validate = validate, label = "combo_box", items = {1, 2, 3}}}}} I've reported this via the Web form.
... View more
‎Jun 28, 2010
02:26 PM
Either have targetPhotos just return 1 photo, Doesn't catalog:getTargetPhoto () return just one photo, the active photo?
... View more
‎Jun 28, 2010
02:16 PM
Am I missing something obvious, or is there indeed no way to set the capture time of a photo? Invoking photo:setRawMetadata ("dateTimeOriginal", LrDate.currentTime ()) results in the error: LrPhoto:setRawMetadata: unknown metadata key "dateTimeOriginal" (The documentation doesn't list "dateTimeOriginal", but I tried it anyway.) If true, this seems like a pretty big omission?
... View more
‎Jun 26, 2010
05:05 PM
Here's an undocumented way to create a dialog with just a single "Done" button. Not sure you want to rely on this though :-; local LrDialogs = import 'LrDialogs' local LrFunctionContext = import 'LrFunctionContext' local LrTasks = import 'LrTasks' local LrView = import 'LrView' local function findButton (x, label, visited) if visited == nil then visited = {} end if type (x) ~= "table" or visited then return nil end visited = true if x._WinClassName == "AgViewWinPushButton" and x.title == label then return x; end for k, v in pairs (x) do local result = findButton (v, label, visited) if result then return result end end return nil end local f = LrView.osFactory() local controls = f:column { f:static_text {title = "Look Ma! No OK or Cancel!"}, f:edit_field {value = "fields"}, f:push_button {title = "Do It"}} LrTasks.startAsyncTask (function () while true do local okButton = findButton (controls, "OK") if okButton then okButton.enabled = false okButton.visible = false return end LrTasks.sleep (0.1) end end) LrDialogs.presentModalDialog { title = "Test", contents = controls, cancelVerb = "Done"}
... View more
‎Jun 25, 2010
10:59 PM
Oh, silly me, I gave you a code fragment that didn't actually make sense -- very sorry about that. The problem with this: local topLevelCollections = LrTasks.startAsyncTask ( function (context) return catalog:getChildCollections() end) is that startAsyncTask does exactly that -- it creates an asynchronous task (i.e. a thread) that executes the function in parallel with the task that called startAsyncTask. It always returns nil, which is why topLevelCollections is always nil. You'll need to put all of the work manipulating collections (and many other methods on catalogs) into a function that's invoked by startAsyncTask. E.g. your plugin could have the structure: local function main () ...access the catalog and collections... ...show the main dialog... end LrTask.startAsyncTask (main)
... View more
‎Jun 25, 2010
02:34 PM
I reported this as a bug via the Web form.
... View more
‎Jun 24, 2010
09:48 PM
Why don't you post the entire code, and maybe it will be apparent what's going on.
... View more
‎Jun 24, 2010
09:33 PM
What you quoted is technically correct, though inconsistent in its use of terminology. In Lua, an "array" is just a table whose keys are numeric. So "(table) An array of LrPhoto objects" is technically correct.
... View more
‎Jun 24, 2010
08:48 PM
1 Upvote
Some resources I found handy when starting out with the SDK: - Look at the sample plug-ins. They provide more examples than what's described in the SDK Guide. - For the Lua lanuage, I found this tutorial quick and easy: http://lua-users.org/wiki/TutorialDirectory The Lua language is conceptually simple but much different than the typical scripting languages like Python, Perl, or Visual Basic. (It's most like Scheme, a language that used to be taught in some computer-science departments years ago.)
... View more
‎Jun 24, 2010
08:24 PM
Oops, I misspoke slightly. The function passed to startAsyncTask doesn't take any arguments: local topLevelCollections = LrTasks.startAsyncTask ( function () return catalog:getChildCollections() end)
... View more
‎Jun 24, 2010
08:16 PM
local topLevelCollections = LrTasks.startAsyncTask(catalog:getChildCollections(), "getChildCollections") startAsyncTask requires the first argument to be a function that takes one argument, a function context: local topLevelCollections = LrTasks.startAsyncTask ( function (context) return catalog:getChildCollections() end)
... View more
‎Jun 24, 2010
07:43 PM
That part of the documentation is wrong. Here's a correct code fragment: local LrApplication = import 'LrApplication' local catalog = LrApplication.activeCatalog () local topLevelCollections = catalog:getChildCollections () local topLevelCollectionSets = catalog:getChildCollectionSets () The documentation for the two catalog:get* methods is correct.
... View more
‎Jun 22, 2010
10:38 PM
The 4-argument form of observer functions passed to observableTable:addObserver appears to be buggy when used with popup menus. After a small number of invocations of the menu, the observer function will stop getting called. I'll report this as a bug soon unless someone points out any misunderstanding I may have. Here's a short test program that illustrates the behavior: local LrBinding = import 'LrBinding' local LrDialogs = import 'LrDialogs' local LrFunctionContext = import 'LrFunctionContext' local LrView = import 'LrView' LrFunctionContext.callWithContext ("Test", function (context) LrDialogs.attachErrorDialogToFunctionContext (context) local f = LrView.osFactory() local p = LrBinding.makePropertyTable (context) p:addObserver ("m3", function (p, k, v) p.e3 = v end) p:addObserver ("m4", {}, function (t, p, k, v) p.e4 = v end) LrDialogs.presentModalDialog {title = "Test", contents = f:column {bind_to_object = p, f:row {f:static_text {title = "3-arg observer: "}, f:popup_menu {value = LrView.bind ("m3"), items = {"A", "B"}}, f:edit_field {value = LrView.bind ("e3")}}, f:row {f:static_text {title = "4-arg observer: "}, f:popup_menu {value = LrView.bind ("m4"), items = {"A", "B"}}, f:edit_field {value = LrView.bind ("e4")}}}} end) You can invoke the menu "3-arg observer" as many times as you want, and its observer will continue to be called (which updates its edit field). But after invoking the menu "4-arg observer" 10 to 20 times, the observer stops getting called. (In my actual plugin, this would happen after invoking the menu just a couple of times.) The problem occurs with my larger catalog (16K photos) but not with a small test catalog.
... View more
‎Jun 19, 2010
03:45 PM
Oh well...
... View more
Copyright © 2024 Adobe. All rights reserved.
AdChoices