Fix range selection in grid mode to make it like on the host OS

[tubalos]

Hello,

Imagine I have 10 photos in my library.

Using Grid mode (on a Mac), if I do:

- click on photo 2

- shift click on photo 4

-> photos 2, 3, 4 are selected

- cmd click on photo 6

-> photo 2, 3, 4 and 6 are selected

- shift click on photo 8

-> photo 2, 3, 4, 5(!), 6, 7, 8 are selected

Photo 5 should never be selected.

This is making keywording pictures particularly tedious for me.

Also, this differs from the macOS behaviour, which it shouldn't.

[tubalos]

Wait! That's not an idea, it is a bug (that's how I see it).

And so I should have created it in Bugs.

Can a moderator move it there?

[Rikk Flohr: Photography]

This step 

-> photo 2, 3, 4 and 6 are selected

- shift click on photo 8

Should be

-> photo 2, 3, 4 and 6 are selected

- cmd - shift click on photo 8

[richardplondon]

As I see it, Shift+click highlights the entire range from the current active image, through to the newly clicked image. And in the absence of the Cmd modifier it does so as a brand new selection, after clearing any prior selection.

So this really hinges on LrC's specific behaviour with OP's shift-click on image 4, and then with OP's cmd+click on photo 6. Did either step change which photo was active, or did it only add further highlighted images while still keeping the same photo active.

The only image conventionally clicked on was image 2. Shift-click on image 8 would be expected to highlight all images 2-8 as a fresh selection - regardless of what was selected or not selected before.

I am not a MacOS user so cannot comment on what usual expectations would be in say Finder. But LrC is not a file browser and has its own internal consistency and usability to consider, including its functional distinction between a most-selected (active) image, and an only incidentally-selected image. The most-selected (active) image is always at the heart of any new action, even if that was not the most recently mouse-clicked image. Otherwise it would be tedious to work in the batch based on a certain photo: because highlighting those other photos too, would have moved the focus away from that image, and then you'd need to re-find and re-activate that without losing your selection.

If either image 4 had became active after its shift-click, and/or image 6 had become active after its cmd-click, the final selection would have been AFAICT 4-8 or else 6-8; and it was 2-8.

[JohanElzenga]

It's true that this behavior is not like how the MacOS Finder acts, but simply adding the Cmd key solves the problem nicely.

[tubalos]

Ok, so the range thing happens because photo 2 is still the 'main' photo, even after clicking on 4, 6 and 8.

I think that what @richardplondon was asking for.

@Rikk Flohr: Photography doing cmd+shift+click on photo 8 doesn't change the 'main' photo which is still photo 2.

I think LR should comply with the host system on the bindings.

LR can still keep photo 2 as the 'main' window so it still does this LR specific thing (the Finder doesn't have a 'main' file when you do multiple range selections).

Since cmd+shift on photo 8 isn't doing nothing more than what a cmd+click on photo 8, I really think it should conform to macOS which is the host system. Why creating a new shortcut for something with no new feature? Keeping photo 2 as the 'main' photo is an LR thing and it could still keep that.

The grid is a file browser (with its own interface/features). It lets you select files (or versions of these files) to apply settings. Except of selecting them directly on the filesystem you select them in the LRDB, but that's about it.

Just like you'd do on the Finder and then read the information of the selection to apply a tag for example.

Note that I am not asking to change the 'main' (active?) photo when clicking. Just conforming to macOS way of doing range selections.

[richardplondon]

IMO it is unwise to regard or to describe the LrC interface as a FILE browser: the items seen there are not files per se. And their management into e.g. Collections / stacking / a custom order, are not file operations in any sense. LrC is a library centric system as opposed to a file based system such as Bridge. As part of that, you can still see and virtually manage images even while their storage location is unavailable. No file browser can do such a thing, nor would people expect or want that. The two, Catalog and file system, are quite different beasts in principle and in intention - even if certain functional dependencies may exist between them.  

The addition of the Ctrl/Cmd key when shift+clicking to select a range of images, is not so that any deselected images within this new range, are going to still remain deselected. That would be at odds with the normal process of selecting a range. The Ctrl/Cmd key prevents any images you already have got selected elsewhere, outside of this new range, from getting deselected. Taking the example again, say images 2-4 are selected. Then you ctrl / cmd click on image 6 to select this also. Then you click on image 6 so it's active. Then you ctrl/cmd + shift click on image 8. Tedious? Sure.

So far more simply, instead you select image 2, shift-click on image 8, then ctrl/cmd click on image 5!

[tubalos]

---

@richardplondon wrote:

IMO it is unwise to regard or to describe the LrC interface as a FILE browser: the items seen there are not files per se. And their management into e.g. Collections / stacking / a custom order, are not file operations in any sense. LrC is a library centric system as opposed to a file based system such as Bridge. As part of that, you can still see and virtually manage images even while their storage location is unavailable. No file browser can do such a thing, nor would people expect or want that. The two, Catalog and file system, are quite different beasts in principle and in intention - even if certain functional dependencies may exist between them.  

---

I was saying it was like a file browser, not a file browser. In grid mode (and even the strip in develop/loupe mode does actually, even if it is only horizontal), it behaves like Photos, iPhoto, or even Aperture back then. And all them supported / support the same mode of selection as the Finder. It doesn't matter wha'ts behind, that's LR job to deal with the selection afterwards. But the selection itself doesn't do LR stuffs, it is just a selection of thumbnails that could just be file (ok, it is not, but it behaves like it, like select and drag for example).

And since the adding of cmd to the keystrokes doesn't do anything LR specific, I think it should be dropped (or not made mandatory, so no regression when you drop that requirement) to match the host OS (macOS here) logic. Don't introduce a logic to a software if it doesn't do something better & specific for it!

---

The addition of the Ctrl/Cmd key when shift+clicking to select a range of images, is not so that any deselected images within this new range, are going to still remain deselected. That would be at odds with the normal process of selecting a range. The Ctrl/Cmd key prevents any images you already have got selected elsewhere, outside of this new range, from getting deselected. Taking the example again, say images 2-4 are selected. Then you ctrl / cmd click on image 6 to select this also. Then you click on image 6 so it's active. Then you ctrl/cmd + shift click on image 8. Tedious? Sure.

---

What do you mean by 'active'? Getting the 'whiter' background? When I do 2-4, then 6, the whiter background is still on 2. And that's where I don't see the point of introducing a new shortcut to not do 'more'.

Now try:

- click on 2

- shift+click on 4

- cmd+click on 6

- cmd+shift click on 8

- cmd+click on 7 to deselect

- shift+cmd+click on 10

I get 2-10 is selected, but if I follow what's being told, I should have 2-4, 6, 8, 9, 10 (that's what you get on the Finder, Photos, iPhoto, Aperture).

So not only it is convoluted, it just doesn't work at all (why resetting the new range index?).

macOS picks from the last highlighted (as the last previously selected in the direction of the next range, but not neceserely the last selected) item in a range to extend the next shift+click selection in the direction of the click.

I'm not sure if you are on a Mac (and if you don't, that's ok, I'm only asking for the Mac plateform because that's the plateform I everyday, all the day). But if you are, open Photos (or the Finder in list mode) and do selections and you will see what I mean by how it differs.

I can't remember selection on Windows, but might actually be the same.

---

So far more simply, instead you select image 2, shift-click on image 8, then ctrl/cmd click on image 5!

---

It is an example. Put more pictures in between and it becomes tedious to the point you can't unselect part of your previous selection.

Let me make a video of that.

[richardplondon]

LrC has a consistent interface and behaviour between Windows and Mac. It works similarly to the Windows file browser selection logic except that shift+click operates from the "active" image and not from the last clicked image.

So shift-click always selects the whole range from the last clicked item (OS) / the active image (LrC), through to the newly clicked item, after clearing any previous selections.

And ctrl+shift-click selects that same whole range, but without first clearing any previous selections.

For any images that were previously selected, or unselected, within (say) the 2-8 range, adding Ctrl does indeed make no difference since those images will be selected anyway. But say you start with images 14, 25, 26, 52 and nineteen other images already selected, and then you do a ctrl+shift-click for 2-8: the result is 2-8 selected plus those other twenty-three images remaining selected.

[tubalos]

---

@richardplondon wrote:

LrC has a consistent interface and behaviour between Windows and Mac. It works similarly to the Windows file browser selection logic except that shift+click operates from the "active" image and not from the last clicked image.

That's exactly where it is wrong. macOS is not Windows and for such a basic operation, it should match the macOS behavior, not the Windows behaviour.

On Windows I do Windows stuffs, on macOS I do macOS stuffs. Softwares should honor that.

---

So shift-click always selects the whole range from the last clicked item (OS) / the active image (LrC), through to the newly clicked item, after clearing any previous selections.

---

I don't think the active image should be the one determining the last click item.

The last clicked item should be the last real clicked item (and keep the Active as the first clicked image since that's an LR thing, and I am not debating which image should be active).

Active image only has a purpose when you do LR operations. Selection images is not an image operation per se, before you ask LR to do things for you that involve reading image data.

- Move files: active is an image but has not impact on the operation

- Synchronising settings: active image is the source of the sync

Having Active impacting an operation that would result in moving files (or even tagging, since tagging takes the selection an an input) is an incorrect behaviour.

If you like it on Windows, why not, though it doesn't more sense than on a Mac.

Actually, it is not Active, it is the lowest file in the sequence (as determine by the current sort) that makes the range feature work incorrectly.

See video "first file in sequence affects range selection"

---

And ctrl+shift-click selects that same whole range, but without first clearing any previous selections.

For any images that were previously selected, or unselected, within (say) the 2-8 range, adding Ctrl does indeed make no difference since those images will be selected anyway. But say you start with images 14, 25, 26, 52 and nineteen other images already selected, and then you do a ctrl+shift-click for 2-8: the result is 2-8 selected plus those other twenty-three images remaining selected.

---

I am not sure I get it. I'd say that you'd get a single contiguious selection.

I am attaching a video "incorrect range selection" showing the impact of making a complex selection when you substract pictures.

Feel free to make a video with the keystrokes showing up, that might be easier to understand each other.

[tubalos]

Also attaching a video of a selection in the Finder (= that's what I'm expecting LR to do on a Mac)