Is there any way to get the current selection?

[Guest]

catalog:getTargetPhotos() returns an array of selection photos, or the filmstrip if nothing is selected. catalog:getTargetPhoto() only returns non-nil if something is most selected.

Is there any way to get an actual selection?

[johnrellis · Accepted solution]

The selection methods are indeed confusing.  This function will return the current selection, or the empty array if there is no selection:

function getSelection ()

     if catalog:getTargetPhoto () then

          return catalog:getTargetPhotos ()

     else

          return {}

          end

     end

[Guest]

Odd. I was sure I had something like this in place, but getTargetPhoto was returning nil unless something was most selected. But now it is working as I expected.

Oh well.

[areohbee]

I wish Lightroom had a unified/simplified targeting scheme, that worked the same for *all* photo processing "commands", like the SDK API doc falsely suggests is the case for getTargetPhotos().

I find it counter-intuitive when something effects a whole filmstrip when nothing is selected, and its definitely NOT consistent within Lightroom proper nor amongst plugins.

My plugins vary (on purpose) whether they target truly selected photos or just get-target-photos: if its non-destructive, I usually target whatever get-target-photos returns, and user can cancel if that's not what they wanted. For destructive things, I target true selections only, and always bother the user with a prompt to confirm..., or sometimes I make the user choose explicitly which they want, either by having a radio button, or a separate menu item for each... - drives me crazy (and them too)...

Hope you are able to find peace and calm in the midst of insanity and chaos, or just like it whirling all mixed up...

Ciao-fur-naw,

Rob

[Guest]

areohbee wrote:

My plugins vary (on purpose) whether they target truly selected photos or just get-target-photos: if its non-destructive, I usually target whatever get-target-photos returns, and user can cancel if that's not what they wanted. For destructive things, I target true selections only, and always bother the user with a prompt to confirm..., or sometimes I make the user choose explicitly which they want, either by having a radio button, or a separate menu item for each... - drives me crazy (and them too)...

Trying to jam in a confirmer into this already overloaded "simple" feature will cause my head to asplode. Unfortunately, the catalog:withProlongedWriteAccessDo() method doesn't seem to actually do anything in a menu context, so my potential easy way of getting a simple confirmer and controlling access to what might be a long write operation on the DB was a bust.

Honestly, what I'm trying to do should be in core product. Even so, I really wish there was a context-menu hook in the SDK so I didn't have to do this strange task dance via the plugin menu.

[areohbee]

Personally, I *never* use with-prolonged-write-access-do. Its of no value other than for scareing the user and providing a modal progress dialog. I think the prompt can be worded more gently without it and a modal dialog box is easy enough to put up if that's what you want. Maybe I'm missing something...

But, regardless, it (or its equivalent) should work just fine as long as your menu handler is started as an async task - it sounds like thats the missing link.

i.e. if your button handler or menu handler or whatever is written as:

if _G.myFuncAlreadyRunning then -- recursion guard

   -- optional: notify user that its already running...

   return

end

_G.myFuncAlreadyRunning = true -- do this synchronously in case user is really quick..

LrFunctionContext.postAsyncTaskWithContext( "my func", function( context )

     context:addCleanupHandler( function( status, message )

        _G.myFuncAlreadyRunning = false -- make sure recursion guard *always* cleared.

       if status then

            -- no uncaught errors were thrown.

       else

            -- message is error message.

       end

    end )

    -- create a progress scope & do stuff... - consider checking for progress-scope cancellation at a minimum, AND shutdown for robustness.

end )

PS - I suspect very few plugin authors would disagree with a context menu hook ;-}

PPS - have shutdown module that sets global shutdown flag, and always check for it in all loops, and never sleep for long without checking it, and you can assure all async tasks are cleaned up "immediately" when plugin is reloaded.

And, as long as the lightning strikes the clock tower at exactly 12:04 then all should be well, right?

R

[Guest]

I'm not sure where you want to place this async function (for me, the mechanics of the async functions are easy, but it is completely unclear how they are called, and how the callers call the other calls), but this is pretty much what I am doing already. It just doesn't matter where I put the prolonged task, and how I form the function passed to it. The function never runs.

There is probably some magic combination of async/sync tasking that unlocks the secret, but this is part of the reason I am tired of bashing my head against it.

It may just be pilot error, but after days of further hackery I am left with the feeling that the a/sync task stuff in the SDK is a glorious mess. Even their own examples barely work beyond the most trivial situation.

[Edit]

BTW, I am not doing a simple model dialog. I present a custom model dialog with some buttons on the initial menu gesture. I gather stuff like the current state of the view (is this my plugin?) so I can enable/disable the various controls immediately. At the same time I collect interesting stuff like the current selection and the published photos associated with those LrPhoto IDs in a tuple.

It is the invocation of the button handler functions that is so tricky (well, some of the aformentioned interesting stuff require a not-very-sensible arrangement of synchronous tasks inside the async model dialog task). I have two button handlers which do different things to slightly different data (based on the selection) but both might eventually write to the database. So the prolonged dialog is actually not that far off from the ideal use.

Depending on how I invoke these functions, I either get the prolonged op dialog, with an accept button that doesn't seem to do anything. Or I don't get the prolonged dialog at all. I can do this without the prolonged dialog, of course, but it either means adding my own confirmer, or just letting the plugin do what it thinks is best, and assume the user has selected the right stuff. Adding a confirmer and status dialog (essentially rolling my own prolonged write code) sounds like the right thing to do, but wrestling with yet more poorly documented SDK stuff and writing kilobytes of boilerplate is not exactly rewarding.

Especially since I have no trust that I will be able to do it -- I expect to get hung up on the exact same sort of "why won't this run now" BS.

As of this writing I can't even get the prolonged dialog to come up at all. This is likely a result of the changes I had to make in order for the first dialog, and the data collection and normalization I have to do there, to work at all.  This is what I mean when I say the a/sync task stuff is a twisty maze of passages, all different. I doubt Adobe even knows completely how this stuff interacts at interesting nodes like user menus.

I'm sure there is some magic that will allow it to work, but my point is that this is not a simple an async model dialog that you build up and then tear down after some trivial processing.

[areohbee]

I get that you are irked and frustrated.

I'm not sayin' its pretty, but if you place that code above in an 'action' (push-button) function, or the like, then it should work.

Note: modal progress scopes require a yield or sleep before they will come up.

R

[Guest]

areohbee wrote:

I get that you are irked and frustrated.

I'm not sayin' its pretty, but if you place that code above in an 'action' (push-button) function, or the like, then it should work.

I have that exact code already. Doesn't work.

Sorry, but this is just the way it is, except my example has a lot more processing. It is hung up somewhere in a thread, but I can't tell where.

A simple example always works.

Also, I am less irked and frustrated by the SDK than you might think. I am trying to patiently explain that the simple solution you offer is, in fact, not going to work. It may work for a simple test, but for a modal dialogue with two button handlers in a menu context I have discovered that most of the usual boilerplate simply will not work.

It will not log. It will not bring up a dialogue. It will not appear to do anything. Obviously, I have to find the magic combination of async/sync commands and sprinkle liberally with yield() and it might work. It is a matter of finding that combo. This is not irksome so much as boring.

I am merely responding to your comments in a conversational manner.

The fact is that I have a fair amount of experience of working with third-party SDKs, and every single time I have done so I have run into similar sorts of problems. It is the nature of the beast.

[areohbee]

Sorry I couldn't be more help - good luck with it.

R

[Guest]

johnrellis wrote:

The selection methods are indeed confusing.  This function will return the current selection, or the empty array if there is no selection:

function getSelection ()

     if catalog:getTargetPhoto () then

          return catalog:getTargetPhotos ()

     else

          return {}

          end

     end

Ok, I see where my confusion was. When you first switch to a collection view, nothing is selected. If you immediately run this code, it will have a selection of the entire view strip. If you select and deselect, then this code works as expected.

[johnrellis]

When you first switch to a collection view, nothing is selected.

Hmm, I'm not able to replicate that. No matter how I select a collection as the source, at least one image is always selected. For example, I created a test catalog with 5 images, and put three of those images in a collection. If I then choose All Photographs, a folder, or a smart collection as the current source, and then choose the collection as the source, at least one image is selected.

Can you give a precise sequence of steps where, when you select the collection as a source, no images are selected?

[Guest]

johnrellis wrote:

When you first switch to a collection view, nothing is selected.

Hmm, I'm not able to replicate that. No matter how I select a collection as the source, at least one image is always selected. For example, I created a test catalog with 5 images, and put three of those images in a collection. If I then choose All Photographs, a folder, or a smart collection as the current source, and then choose the collection as the source, at least one image is selected.

Can you give a precise sequence of steps where, when you select the collection as a source, no images are selected?

I mean that nothing /appears/ selected in the UI, even though it is in the SDK. This is slightly unexpected, because it means it is possible for someone to invoke the plugin menu I added without realizing anything is selected. There is no indication that anything is selected (except for the Navigator, I suppose.)

By "selected", I mean that the Lr UI is not showing any photos as selected or most selected. Programmatically, switching to a collection automatically "selects" either some default item in the collection (the "first" one, perhaps) or a photo that was selected in the UI in another collection when you switch the view to a publish selection that contains that photo.

Basically, I'm trying not to let a simple gesture blow away photo metadata, which is what my two dangerous buttons are doing.

[johnrellis]

I mean that nothing /appears/ selected in the UI, even though it is in the SDK. ... There is no indication that anything is selected (except for the Navigator, I suppose.)

This is what I can't reproduce -- whenever I select a collection as a source, the LR user interface shows at least one photo as selected.

This may indicate a bug in the LR user interface, rather than the SDK itself.  There may be something very particular to your catalog or configuration that is triggering this bug and it may not in general happen to your users (or it may).

Thus, if you can provide a precise recipe for triggering the bug in the user interface, I can see if I can reproduce it, and we can narrow down the circumstances of how it occurs and file a useful bug report.  (It's pretty clear from the LR 3.5RC release notes that Adobe is reading bug reports in the new feedback forum and responding to them.)