Lightroom SDK: plugin preferences are tied to name of plugin folder.

  • 1
  • Problem
  • Updated 7 years ago
-previous content deleted-

I figured out the cause of the problem:

I've been passing _PLUGIN object to LrPrefs.prefsForPlugin instead of _PLUGIN.id (or nil). That ties the preferences to an amalgamation of the plugin object that includes the plugin path (instead of the id), so if the plugin folder is moved or renamed the preferences are no longer found. Whoa - I owe all my plugin users who've moved their plugins and lost their preferences an apology (and they owe me one for not reporting the problem). I normally execute the same plugin from the same folder, so I hadn't noticed a problem.

I have a problem to deal with due to my mistake, but it may not be a bad idea for Adobe to consider checking that the argument to LrPrefs.prefsForPlugin is valid.

UPDATE:

Here's my solution, for those who have to know - automatically migrate wrongly stored prefs to where they should have been stored in the first place - this in lr-init-plugin module:

-- migrate legacy preferences:
local function prefsEmpty( p )
for _,__ in p:pairs() do
return false
end
return true
end
local legacyPrefs = LrPrefs.prefsForPlugin( _PLUGIN )
local newPrefs = LrPrefs.prefsForPlugin( _PLUGIN.id ) -- this presently does the exact same thing as passing nil and letting it default (I *think*).
-- the reason I pass the id explicitly is to make it clear the difference between prefs used in framework/plugin, and those used in debug module, which are separate.
local legacyEmpty = prefsEmpty( legacyPrefs )
if not legacyEmpty then
local newEmpty = prefsEmpty( newPrefs )
if newEmpty then
LrDialogs.message( "Migrating legacy preferences - this should not happen again." )
for k, v in legacyPrefs:pairs() do
newPrefs[k] = v
legacyPrefs[k] = nil
end
else
-- wipe legacy prefs so the following message does not keep coming up.
for k, v in legacyPrefs:pairs() do
legacyPrefs[k] = nil -- legacy should be empty next time.
end
LrDialogs.message( "New preferences were chosen over legacy preferences.", "You may have to redo your settings in plugin manager - sorry for any inconvenience this causes - this should not happen again." )
end
end

UPDATE #2: Just found these notes:

"I had an error: 'table too nested' that I was only able to fix by passing _PLUGIN (sans .id) to prefsForPlugin function." - i.e. the origin of the problem was back when I was using tables in preferences, instead of simple elements. the prefs were so wonked that I couldn't even get a reference to them anymore in order to clear the problem, resorting to what was effectively the abandonment of the prefs for a new set (unbeknownst to me at the time).

"Table prefs, although supported, is 150 times (for me on Windows 7/64) slower than accessing the same data items using separate non-table entries." - related problem???

Bonus Idea: a method: LrPrefs.clearPrefsForPlugin() that will wipe out prefs in a single stroke, whether wonked or not.

R
Photo of Rob Cole

Rob Cole

  • 4831 Posts
  • 379 Reply Likes
  • recovering from a harrowing setback...

Posted 7 years ago

  • 1

Be the first to post a reply!