Images to Act On - How Should It Work?

[elstoc]

Now that a lot of the decision making around image selection in the lighttable and thumbtable is centralised into a single function (dt_view_get_images_to_act_on) I thought it might be time to talk about how it works and come to a consensus on how we can make it a little more user-friendly.

Here's now it works right now:

                mouse over| x | x | x |   |   |
        mouse inside table| x | x |   |   |   |
    mouse inside selection| x |   |   |   |   |
             active images| ? | ? | x |   | x |
                          |   |   |   |   |   |
                          | S | O | O | S | A |
     S = selection ; O = mouseover ; A = active images
     the mouse can be outside thumbtable in case of filmstrip + mouse in center widget
   
     if only_visible is FALSE, then it will add also not visible images because of grouping

I find myself constantly consulting the above table and still have trouble keeping it in my head. And I don't think I'm the only one who sometimes finds it confusing. Given the number of bug reports and discussions where this comes up it may be better if it were a little more simple/intuitive or perhaps if some of its behaviour could be simplified via preference settings or flagged better in the UI.

For example, probably the most commonly used mode in the lighttable is called 'file manager'. Most users would probably expect it to work (within reason) like a standard file manager and in this mode at least, being able to perform actions just by hovering over images and hitting key combinations is decidedly non-intuitive. And it gets even odder when you have multiple images selected but are inadvertently hovering over an unselected one.

Anyway, I've just opened this for discussion to see whether there might be a better way.

[johnny-bit]

Well, It's mostly intuitive except for mouseover - so if mouse is inside selection, the get images to act on will return whole selection. if mouse is hovering over different image then (uh... correct me if i'm wrong) it'll return only the mouse-hovered one?

So the rule IMO should be: if there's a selection going on preffer selection over mouseover and it'd prooobably save much headeaches.

[aurelienpierre]

I have always found the behaviour of the lighttable confusing. If you select a thumbnail (click), then hover the mouse somewhere else, then move arrow keys, it's the hovered thumbnail that gets updated.

I think selection (for edit or export) should rely on click/arraw only, and hover should only be used to display transient info (read-only) like metadata. Mouseover should be ditched for everything else. Selection (actively and explicitely done) should be the only reference for every export, edit or action triggered in GUI.

[elstoc]

I think selection (for edit or export) should rely on click/arraw only, and hover should only be used to display transient info (read-only) like metadata. Mouseover should be ditched for everything else. Selection (actively and explicitely done) should be the only reference for every export, edit or action triggered in GUI.

Totally agree. My understanding though is that arrow key (to navigate) doesn't change selection at the moment but acts the same as a 'mouse hover'

[junkyardsparkle]

Some people seem to really like the hover-selection, so this will probably be contentious. Personally, I've been hoping for an option to disable it from day one. I would also think disabled would be a safer default for new users, but that's just me. For heavily mouse-oriented people it isn't as much of a problem, because placing the pointer on a button to execute an action inherently moves it off of the thumbnails. For keyboard oriented people, it's insanely dangerous.

[AlicVB]

Now that a lot of the decision making around image selection in the lighttable and thumbtable is centralized into a single function (dt_view_get_images_to_act_on)

Yep, this as been done with that in mind (not only)

Now, for the rest of the discussion, I agree that this behavior may be confusing for some people and not just newcommers which may be confused by far more than that anyway ;)
On the other hand, the current behavior can be really handy once you are used to it. I use that quite often and I know for sure that other users and devs use i it a lot too.

What I would propose is to have a pref to switch to another "image to act on" algorithm.
For defining how it should work, I think the table mentioned in first post can be a good starting point. The delicate area is -of course- the filmstrip...

[elstoc]

There are also probably some view-specific special cases we need to consider. For example

• If a single image is selected but it's not currently visible, perhaps operations should not consider it as being selected (user might just have clicked without meaning to select)
• If lighttable view shows only one image at a time, selections should be ignored and actions should be carried out on the currently viewed image whether or not the mouse is hovered over it

[elstoc]

I'd be interested to know what 'Active' means in the table above.

[jobec]

Like mentioned above, hovering can be powerful and allows for very fast actions. But it should not be the default.
E.g. if anything is selected (by a simple click, ctrl+click, shift+click etc etc), hovering should be totally disabled and do nothing.
If nothing is explicitly selected (by single clicking on a selected image to unselect it), mouse hovering is what defines the selection.

I'm not sure if my explanation is clear, but I think that'll be most intuitive and match with how file browsers or even digikam works.

[AlicVB]

I'd be interested to know what 'Active' means in the table above.

active images are the one(s) shown in central view in modes with filmstrip (preview, culling, darkroom)

[github-actions]

This issue did not get any activity in the past 30 days and will be closed in 365 days if no update occurs. Please check if the master branch has fixed it and report again or close the issue.

[RawConvert]

This is still happening in 3.4.
There have been a number of issues raised about it which seem to have been distilled into this one.
I think it deserves a decent push towards a fix!

[jobec]

I left darktable behind in the meanwhile.
I got so fed up with all the quirks in the GUI that I spent more time clicking around then actually working on images.
I know some think the way it works is a "feature" and that you get used to it, but it is not. It deviates from the unwritten and implicit GUI rules all software seems to use.

On a sidenote: one other thing that pushed me away was the filmic RGB stuff. It's a brilliant module, don't get me wrong, but I never managed to get the results I wanted and never really understood the logic behind it. And I don't want to become an image scientist just to know how to use something.

I find this a pity, because the potential of darktable is gigantic and I am a heavy fan of opensource. Maybe I revert back to it some day...

[RawConvert]

@jobec , each to their own of course. I think dt is very good overall, but could be a step better if various basic quirks and bugs were sorted out.

[elstoc]

@RawConvert we need to come to some consensus as to the way forward before we can progress to coding it. Right now it's all working "as designed" but we need to decide if we want to change the design or maybe implement some different alternatives that are selectable as a user preference.

[Nilvus]

@RawConvert we need to come to some consensus as to the way forward before we can progress to coding it. Right now it's all working "as designed" but we need to decide if we want to change the design or maybe implement some different alternatives that are selectable as a user preference.

I think having an alternative could be good. And the behavior should be by default consistent with other applications to help new users use darktable. So, something with proposal in #8898 and @aurelien comment above should be default one, and actual one an alternative. Probably the simple way. If this could be implemented in 3.6, that would be great and limit new issues about that. But of course, it remains few time to do that.

[RawConvert]

hi, my eyes have had a problem and I've been out of things somewhat, anyway getting better now and in fact built a new dt a few days ago. I don't know why I never responded to @elstoc in Jan, apologies for that. So here is my 2p worth...
I'll re-iterate that I think things like hover-to-delete, and ignoring a selection in favour of a hover, are wrong. I agree with comments above along the lines of behave like a normal file manager and just use hovering for pop-up info.
I don't use the filmstrip and always use lighttable in "file manager" mode, so am not qualified to comment on functionality like culling.
@elstoc said above "If a single image is selected but it's not currently visible, perhaps operations should not consider it as being selected (user might just have clicked without meaning to select)" Going back to normal OS file manager, it is surely fine to select a subset of files and scroll down to select more. They may go off the screen but you explicitly selected them so they are acted on. Same with lighttable surely?
Also "If lighttable view shows only one image at a time, selections should be ignored and actions should be carried out on the currently viewed image whether or not the mouse is hovered over it" Sometimes I only have one image loaded, I'm in darktable, back to lighttable to export, but it's not selected, surely in this situation it should be?
Having a preference to control how mouseover works seems ok providing the default is "mouse does popup info only". However settings like this presumably contribute to code complexity and scope for bugs?

[AlicVB]

As said earlier, the code has been done to allow more easily multiple implementations of dt_view_get_images_to_act_on
Personally, I'm very pleased with the actual implementation, but I can understand that other would prefer a more "classic" approach...

Lighttable filemanager in zoom > 1 is the easy part.
What is challenging is the other modes, the interaction with filmstrip, the acceptance (or not) to loose or complexify some features (like multiple copy paste)
An example with culling with 2 images : you have to choose what happen when :

• the mouse is outside the central area and the filmstrip
• the mouse hover an image in the central area with 2 cases : selected or not
• the mouse hover an image in the filmstrip, with 2 cases : selected or not

We also have some actions that can only take one image into account : copy, 'd' shortcut, etc...
All this needs to be consistent between views / cases...

Of course, I'm ready to help listing all this if someone is brave enough to step in ;)

[elstoc]

I think the main thing for now that would significantly ease some of the pain for new users, would be to have an "ignore hover" option. Is that hard to do?

[AlicVB]

Is that hard to do?

Sadly, yes... because there's features that rely on it : metadata view is an example, but I'm sure we can find lot of others. There's also cases where we just can't ignore hover : culling mode is an example : if you hover an image and press 'r' : you don't expect to reject all your selection...
From the code point of vue, that would mean writing an alternative dt_view_get_images_to act_on which is not a problem but need to be though carefully...

[aurelienpierre]

I maintain what I said a year ago. Very often, because I kick the mouse or because palm rejection on touchpad still sucks on Linux, I end up with an unexpected file being exported or rated (with the stars). "Act on hover" is simply brittle. Acting should be done after clicking on something hard (button or key), so there is zero ambiguity about the selection ; it's simply too easy to have an erratically moving cursor.

[Solarer]

Looks like the consens is that we need a draft so that we can discuss it here properly. I will collect the information that I found in other issues so far and write down something that we can talk about. I should find some time during the weekend.

Can somebody explain to me what the small table in the first post should represent? I get the values on the left - they describe in what state a picture is in. But what does it mean if there is a [X],[space],[?] in column 'O' and why do we have O and S twice?

[AlicVB]

I can just encourage one to try to work for just 5 minutes in the way I described, and I am very confident that you'll run into the problem. Alternatively, I will gladly record a screencapture-movie of my workflow and cut it down to a moment where you'll nicely and clearly observe the problem.

that would be great, because what you describe is clearly a bug. Can you open a new issue for that, thought, as it's not related to the discussion here and should be fixed independently of the act-on algorithm... Thanks !

[airflow2010]

that would be great, because what you describe is clearly a bug. Can you open a new issue for that, thought, as it's not related to the discussion here and should be fixed independently of the act-on algorithm... Thanks !

Sure! Here you have two examples of the same problem. In the first example, I use the zoom-feature. In the second example, I don't. But the principle is the same. I used an additional software ("Screenkey") to display the keys I pressed during recording, so you can see exactly what I'm doing. In the comments of the video you see a more detailed explanation with the info of exact moment of problem.

I will open a new issue for that as requested, please just let me briefly know that you still agree that's actually a bug and not some kind of misunderstanding from my side.

[AlicVB]

yep, seems like a bug... When you fill the new issue, can you provide a step by step as detailed as possible, so we try to reproduce (I can't actually) Thanks !

[rekcodocker]

The worst offender, though, is when you purposely select multiple images (with shift+click and/or ctrl+click) and then accidentally apply changes to an unselected image just because you happened not to be hovering your mouse over any of your chosen images at the time you pressed the shortcut. That behaviour is just plain dumb

True, that makes no sense ever.
Best (most logical) behaviour is:

• if you have something selected, then hovering does nothing.
• if you have nothing selected, then hovering will determine where an action takes place.

I.e. clicking is a firm positive confirmation. Moving your mouse over something is also a meaningful action but should never override clicking.

[ptilopteri]

since inception this selection method has been the default in dt and I have become
accustomed. but as an alternative, why not consider the image below the mouse as
"selected" unless selected images exist?
maybe that can be the best of both worlds?

[github-actions]

This issue did not get any activity in the past 60 days and will be closed in 365 days if no update occurs. Please check if the master branch has fixed it and report again or close the issue.

[Nilvus]

Just a thing, another issue related to that one: #14462. Maybe this should change and I'm with @elstoc here to change that. This is really needed to improve UI and user-friendly app. Just be like others apps here. I hope this could change for 4.6. @Solarer: you have worked on that (and culling mode). Possibility to see updates on your work?

[Solarer]

@Nilvus I created a PR in January for @AlicVB to review but I got no feedback so far. It is not perfect yet but I wanted to discuss the overall idea before spending more time on it.
The PR is a prerequisite for this discussion and does not solve the act-on problems yet.

You can find it here: #13278
I will rebase the code after I received an 'ok' to proceed or feedback what to change.

[gi-man]

I would love the option to disable the Act On mouse hovering. I keep rejecting the wrong image (not the one selected, but the one the mouse is at).

[rekcodocker]

This is really needed to improve UI and user-friendly app. Just be like others apps here.

Exactly this. There is quality in consistency. Sometimes it is more userfriendly to not be special but be like other apps.

[oijn]

If I forget to "park" my mouse pointer off screen somewhere - when I select images in lighttable with arrow keys and spacebar - when the displayed image table is shifted as the page scrolls - the highlight jumps to the image under the mouse pointer and not the logical next image. This just add hundreds or on a large library thousands of extra arrow key presses just to go over the images you've already arrowed over and can add ten plus minutes to a simple selection task.

For the last many months - I just thought that this was a specific darktable bug - well at least I know now that this is a unique darktable feature.

[elstoc]

For the last many months - I just thought that this was a specific darktable bug - well at least I know now that this is a unique darktable feature.

Honestly for this one, I'd be tempted to use the term "intentional bug". I guess I'm used to it now after many years but it's still wrong.

[Solarer]

@elstoc and @Nilvus, I am still waiting for a review by @AlicVB on my PR but he does not seem to be very active on github since the beginning of the year. Do you know if he will be back soon or can someone else give feedback to the code?

[AlicVB]

I'm sorry to be so unavailable these days : my "real" job and some graduations are taking up all my free time...
Especially in this case, as this review requires lot of time and thinking.

I still hope to do it this month (but I've already said that last month...)

[github-actions]

This issue has been marked as stale due to inactivity for the last 60 days. It will be automatically closed in 300 days if no update occurs. Please check if the master branch has fixed it and report again or close the issue.

[londeril]

Hello all,

Introduction

Longtime Lightroom Classic user here - I've only very recently looked into Darktable and I'm currently in the process of switching over to it because I love the image pipeline that much going back to Lightroom to try things out feels "stale" and quite "limiting" - so first of all THANKS to everyone who is or has written code for this amazing project!

The issue

I've been searching around the interwebs and this github because I found the "Act-on-hover" thing DT does quite disorienting. I understand the logic behind it and I can see the benefits of it (I'm a "focus follows mouse" guy since forever) so I can get my head around the fact that the mouse hover selects an image (though I'd still prefer it to be an option to turn this off and have "normal" click to select functionality).
BUT - the "Act-on-hover" gets very weird and I think even "workflow impeding" when using the arrow keys to navigate the Lighttable view. The way I like to use the Lighttable is to have rather big thumbnails for a quick overview in my culling process and use the arrow keys to select the next image or go back to the previous one. this works fine as long as the Lighttable view stays "on the same page" as soon as the images get "pushed up" (or down) to make room for the next row - and the mouse hovers over an image (like in the middle of the screen) that image gets selected and pressing the arrow keys will select the next image starting from there... this is very confusing... and now that I write it down I realize that it's also quite hard to show in text... so I made a screen capture off it (with sample images to for privacy concerns, naturally):
https://streamable.com/ze5n3g

This can be mitigated by simply moving the mouse out of the Lighttable (over a module, or over the window decoration) but I feel like this should not be necessary.

Yeah... well... in the end I just wanted to add this to the conversation - forgive me if that has been discusses before - this issue has been open for a long time, I see ;)

[Solarer]

@londeril thanks for sharing your finding. The issue you describe is not actually caused by the act-on code, so it can be fixed independently 😉

Please open a new ticket and add your video there

[londeril]

@Solarer will do :)

[github-actions]

This issue has been marked as stale due to inactivity for the last 60 days. It will be automatically closed in 300 days if no update occurs. Please check if the master branch has fixed it and report again or close the issue.