8 Replies Latest reply on Apr 6, 2013 9:01 AM by areohbee

    Feature Request: a way to retrieve accurate plugin disable/enable state

    areohbee Level 6

      As it stands, LrEnablePlugin file is executed when plugin goes from disabled to enabled, and LrDisablePlugin is executed when plugin goes from enabled to disabled. Unfortunately its really hard to glean useful information because:


      plugin will go from enabled to disabled then back to enabled when new metadata is added and such stuff, and there is no way to tell whether plugin is enabled or disabled after a reload, since neither module is executed unless there is a change.


      It would be useful to me to be able to simply read an accurate status: enabled or disabled.


      Also, if Lr needs to disable for a moment to add metadata, I'd rather have the state not reflect the temporary disablement, unless reenabling fails and it becomes permanently disabled, or better still, have it reflect the temporary-ness of the disabled state, so maybe these states:


      disabled permanently

      disabled temporarily (e.g. to add metadata)

      enabled permanently

      enabled temporarily - for case when user attempts to enable but catalog neds updating, in which case if update fails it will be re-disabled.



      If this is too much, at least a minimal improvement could be had by simply having LrEnablePlugin and LrDisablePlugin not be called when Lightroom disables/enables for the sake of metadata / catalog updating, so they're only called when user clicks the buttons. This would not be as useful as accurate live status, but at least would eliminate disable / enable actions that assume the user did something he/she did not...

        • 1. Re: Feature Request: a way to retrieve accurate plugin disable/enable state
          DawMatt Level 3

          Hi Rob,


          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?



          • 2. Re: Feature Request: a way to retrieve accurate plugin disable/enable state
            areohbee Level 6

            HI Matt,


            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...
            function App:isPluginEnabled()
                local ena = rawget( _G, 'enabled' )
                assert( ena ~= nil, "no ena" )
                return 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()[1] -- 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 true
                    return false, msg
                --local ena = rawget( _G, 'enabled' )
                --assert( ena ~= nil, "no ena" )
                --return ena





            • 3. Re: Feature Request: a way to retrieve accurate plugin disable/enable state
              DawMatt Level 3

              Hi Rob,


              Think I understand the situation now.  Looks like I'll be lodging a feature request over this.  Have you written up this one yet?



              • 4. Re: Feature Request: a way to retrieve accurate plugin disable/enable state
                areohbee Level 6

                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...



                • 5. Re: Feature Request: a way to retrieve accurate plugin disable/enable state

                  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 (?)
                                      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 )))
                            LrDialogs.message("The needed Plug-In is NOT enabled!","Install/enable 'rc Exif Meta'!")
                  --all set, basically operational



                  The code works alright, but I believe it could be improved quite a bit. Any ideas/suggestions?

                  Thanks for feedback.

                  • 6. Re: Feature Request: a way to retrieve accurate plugin disable/enable state
                    areohbee Level 6

                    I don't know of a better way. Fingers crossed for Lr5...

                    • 7. Re: Feature Request: a way to retrieve accurate plugin disable/enable state
                      DawMatt Level 3



                      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?



                      • 8. Re: Feature Request: a way to retrieve accurate plugin disable/enable state
                        areohbee Level 6

                        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.