Lightroom SDK: catalog:setPropertyForPlugin requires full write access, not just private...

  • 3
  • Problem
  • Updated 7 years ago
API doc says it needs "one of the with-do" gates, which implies:

- withWriteAccessDo, *or*
- withPrivateWriteAccessDo

Most functions throw an error when you try to use private write access when full access is required. This one does not. But it is definitely only reliable with full write access. (I could swear it also has potential to work sometimes with only private write access, but I'm questioning my sanity about that now). But I definitely fixed two broken plugins recently by changing access from private to full, that much I'm sure of.

So, one of two things needs to happen to make it right:

- fix functioning with private write access
- amend documentation to indicate full write access is required, and throw error if only private write access has been granted.

PS - I mentioned this in a previous thread but only after it had been marked "not a problem" and there was no more acknowlegement from Adobe - thus this as new issue.
Photo of Rob Cole

Rob Cole

  • 4831 Posts
  • 372 Reply Likes

Posted 7 years ago

  • 3
Photo of john beardsworth

john beardsworth

  • 961 Posts
  • 199 Reply Likes
Rob, why not remove the private method? I may be betraying that I'm not a trained programmer, but is there any need for it?

John
Photo of Rob Cole

Rob Cole

  • 4831 Posts
  • 371 Reply Likes
I'm not qualified either to say how best to fix this - I think its Adobe's realm...
Photo of jdv

jdv, Champion

  • 728 Posts
  • 55 Reply Likes
The main difference (from an SDK consumer POV) is that the private one doesn't place your change in the undo list.

So, as long as this is still part of the SDK spec...
Photo of Rob Cole

Rob Cole

  • 4831 Posts
  • 371 Reply Likes
Excellent point John. And, for that reason, it would be much better for the catalog properties to be writable with private access, as specified. I just looked at the undo list for plugins using the catalog properties and the plugin stuff in there should definitely *not* be undoable by the user. Thanks for pointing that out...
Photo of Rob Cole

Rob Cole

  • 4831 Posts
  • 372 Reply Likes
Reminder: this function, as it stands, is not fit for normal plugin consumption.

Generally, one does not want their users fumbling through undo operations that were internal to the plugin.

I am re-coding to work around...

Adobe - please resolve reliability issues using private write access.

(it really does work just fine sometimes with private write access, but really does not save the data that it says it does sometimes with only private write access (does not throw error, just doesn't work...). Again, so far I have not discovered any problem when using full write access, except for the undo entry...
Photo of Rob Cole

Rob Cole

  • 4831 Posts
  • 372 Reply Likes
Present work-around:

- convert catalog path to pref-key compatible format (eliminate f/b slashes, dots, colons, spaces, and dashes - I think that's all(?)).
- prepend the converted catalog path to name of property and save in Lr prefs-for-plugin.

I like it! - Note: this would not be a viable solution if you *need* for it to *not* work in case of some problem in a related with-do function, but so far I only need it *to* work, so circumventing the with-do gate is actually a big plus.
Photo of jdv

jdv, Champion

  • 728 Posts
  • 55 Reply Likes
I've needed to use it twice, and it works in one case all the time. In the other, it fails miserably.

I'm guessing there is a context it likes to run in, and anything outside of that path may be problematic.
Photo of Rob Cole

Rob Cole

  • 4831 Posts
  • 371 Reply Likes
Does it fail with *full* write access too?

Try just using reglar prefs-for-plugin, with a catalog prefixed property name (see above). - At this point, I don't care if it ever gets fixed... But obviously, it need to be either fixed, re-documented, or yanked altogether...

-R