I think I understand this, but the explanation was a little hard to follow. Especially if you subscribe to the forum via emails as you only see the original version of a post. The additions made later have helped though - thanks.
When you refer to adding metadata I assume you are referring to adding metadata definitions for use by the plugin. Is this correct? I first read the reference to metadata as changing metadata values (e.g. modifying the title of a photo) which doesn't seem likely.
It sounds like you would like to see something closer to the way the endDialog() function works, with a reason parameter being passed to the executed code. Makes sense to me. I'd be tempted to suggest these temporary disablements be completely hidden from the plugin, as it is a Lightroom internal operational detail and the plugin isn't really disabled. But if you have a background thread running and performing operations it might need to know the current state and act appropriately even during this type of disablement. So it is probably better to expose this state information and allow the plugin to ignore it if it doesn't impact its operation.
Have I correctly understood what you were proposing?
Sorry - it was late...
Anyway, I think you've got the jest of it. To help clarify further:
There are two issues with the way things are enable/disable-wise:
1. there is no way for a plugin to tell if it is enabled or disabled.
Here's a cut from the framework:
--- Determine if plugin is enabled.
-- @usage Note: do not depend on this reporting correctly, since default value for 'enabled' is true
-- even when plugin is disabled. Its only correct after plugin goes from enabled to disabled or vice versa after init...
local ena = rawget( _G, 'enabled' )
assert( ena ~= nil, "no ena" )
2. The enabled / disabled modules are executed upon temporary disablement / reenablement as well as the more permanent flavor, so they cant really be used to prompt the user, or multiple confusing prompts get issued when the state is bouncing around...
As usual, I'd like to see this improved in the next version, but I'm also open to suggestions for working around it in the mean time...
PS - I just thought of a work-around for the first issue (which primarily arises in plugins that access plugin metadata) - just try and get a known-to-be-defined metadata item - iff successful, then the plugin is enabled.
So, a possible solution:
1. Have a readable (and preferrably writable too) enable/disable state that accurately reflects right-now enable / disable state - even if temporary.
2. The ability to determine root cause of disablement, e.g. "temp-for-catalog-update", "permanent-since-catalog-update-failed", "user-initiated", ... I can imagine root cause for enablement to be useful too...
*** UPDATE: Modified method:
--- Determine if metadata-supporting plugin is enabled.
-- @param name (string, default dummy_) name of alternative plugin metadata item (property) to be used.
-- @param photo (lr-photo, default 1st photo of all) photo to use to check.
-- @usage This method presently only works when a metadata item is defined. Maybe one day it will also work even with no plugin metadata defined.
-- @usage Only works from an async task.
-- @return enabled (boolean) true iff enabled. Throws error if not called from async task.
function App:isPluginEnabled( name, photo )
assert( catalog, "No catalog." )
name = name or 'dummy_' -- cant start with underscore.
photo = photo or catalog:getAllPhotos() -- getting all-photos takes ~16msec.
assert( photo, "No photo." )
local _dummy, msg = photo:getPropertyForPlugin( _PLUGIN, name, nil, true ) -- nil version, no-throw.
if msg == nil then -- msg is nil if property defined and plugin enabled, even if property value is nil.
return false, msg
--local ena = rawget( _G, 'enabled' )
--assert( ena ~= nil, "no ena" )
Think I understand the situation now. Looks like I'll be lodging a feature request over this. Have you written up this one yet?
I have not (logged this one officially).
Once I developed a work-around, I kinda quit thinking about it.
So far, the only plugins that care whether its enabled or not have metadata, and the check for reading a known metadata item accurately determines enable / disable state.
Still I think its a good idea to log the official request - how about you go ahead with it, eh?
I'll do one too if you think it would help to add some squeak to the wheel...
To Matt or Rob,
what's the status about this issue: plugin xyz enabled/disabled?
This is what I've got so far to see if 'rc Exif Meta' is enabled.
--make sure the needed Plug-in 'rc Exif Meta' is enabled by simply reading some data provided by that plugin. local foto = catalog:getTargetPhoto() local plugInIds = foto:getRawMetadata( 'customMetadata' ) --LrDialogs.message(string.format( "Name of Table for 'plugInIds': >%s< ",tostring( plugInIds ))) if not ( plugInIds == nil ) then for i, v in ipairs( plugInIds ) do if v.sourcePlugin == 'com.robcole.lightroom.ExifMeta' then --this is the unique plugin ID -- consider v.id and v.value.... -- LrDialogs.message("Table 'plugInIds'", "nv.id: " .. tostring(v.id) .. "nv.value: " .. tostring(v.value)) -- LrDialogs.message(string.format( "Name of Plug-In enabled: >%s< ",tostring( v.sourcePlugin ))) --LrDialogs.message(string.format( "Needed Plug-In is enabled: >%s< ",tostring( v.sourcePlugin ))) break --hope this is allowed here (?) else if string.format(v.sourcePlugin) ~= nil then LrDialogs.message("The needed Plug-In is NOT enabled! ","ID of enabled Plug-in(s) are: " .. tostring( v.sourcePlugin )) --LrDialogs.message(string.format( "Name of other Plug-In enabled: >%s< ",tostring( v.sourcePlugin ))) ProgressScope:done() return end end end else LrDialogs.message("The needed Plug-In is NOT enabled!","Install/enable 'rc Exif Meta'!") ProgressScope:done() return end --all set, basically operational
The code works alright, but I believe it could be improved quite a bit. Any ideas/suggestions?
Thanks for feedback.
I don't know of a better way. Fingers crossed for Lr5...
For a while now I've just been testing this value:
It has always been accurate as far as I can tell.
The SDK for LR4 documents this in the LrPlugin API Reference page. It works in LR3 as well but I can't remember if it was documented at that time. If you need to support LR2 and also be aware of the enabled status then you need to use complicated tests like Rob had in his code but you shouldn't need that for LR3 onwards.
Rob, was there any particular reason you didn't just use _PLUGIN.enabled in your code? Was it just because of LR2 support, or is there some bug that I don't know about?
I do use _PLUGIN.enabled now exclusively for testing current plugin enable/disable status - works fine.
You still need the complicated stuff to determine *other* plugin enable/disable status, which is what snahphoto is trying to do.