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[bot]]

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]

But what does it mean if there is a [X],[space],[?] in column 'O' and why do we have O and S twice?

It's my work, so apologize if I were cryptic... x : condition validated space : condition not validated ? : condition validated or not

For the bottom line, it's the image(s) we return... effectively, there is cases where we return the same set of images...

read the table column by column from left to right :

• if col1 is validated then return selection (S)
• otherwise if col2 is validated return hovered image (O)
• otherwise if col3 ...

[Solarer]

Thanks, now it makes sense. But isn't

selection with mouse over > mouse over > active > selection

A simpler but equivalent representation? Where A > B means that B will not be used if A is available.

[Solarer]

Edit: added a few issues and specified 'intuitive' as 'similar to other filemanagers' instead of 'friendly to new users'.

Here is a list of related issues that have been posted in the past:

• #4558: Complains that hovering takes priority over selection.
• #5895: Selection has no effect in culling modes because 'active' images always have higher priority.
• #5984: Hovering an image in the filmstrip in culling should not take priority over active images. (I personally do not agree with this one)
• #5987: Complains that hovering takes priority over selection.
• #6064: General confusion over the behavior of mouse over + selections.
• #6313: Behavior of 'mouse over + selected' pictures is unintuitive.
• #6625: When entering culling mode via 'X' button, accidental movements of the mouse or even the starting position might change whether actions are applied to all active pictures or only one (https://github.com/darktable-org/darktable/issues/6625#issuecomment-740207408).
• #7254: Images in culling mode cannot be selected with a single left click as in filemanager & Mouse over is not always plain visible and therefore prone to errors. #7805: People find it unintuitive that you cannot select something in culling mode with a regular mouse click (related to #7000 and #5138)
• #8898: Selection has no effect in culling modes because 'active' images always have higher priority.

So it seems to come down to the following points: a) The current interaction between mouse over and selection feels inconsistent and unintuitive b) The 'priority chain' of dt_view_get_images_to act_on is problematic in culling (fixed) mode because at least one picture is always active and has higher priority than any selection. c) Working with selections in culling modes is completely different than in any other mode d) The experience is not always clean when using mouse / keyboard / mouse+keyboard

Goals The solution needs to be consistent throughout all lighttable and darkroom modes and should ideally be intuitive (similar to other OS filemanagers). It must support all common (and reasonable!) workflow steps with mouse, keyboard and mouse+keyboard. Safety against unintentional actions might be an additional goal.

I most likely forgot something so feel free to comment.

[RawConvert]

@Solarer , good to see someone taking a bit more of an overview on this, to complement the code-oriented approach. Where you say under Goals about being consistent and intuitive, I'd say reasonable compatibility with your average file manager is a good goal. I don't think we should emphasise new users too much, I think lots of users find the behaviour odd who are not new users, e.g. Aurelien P! And I think safety is not just an additional goal, it's pretty important. I think there are other issues you could add to your list - #4558, #5895, #5564 possibly, #5987, #5984...

[Solarer]

@RawConvert thanks for that. I added all of your issues except #5564 because it seems to be unrelated and might have been fixed already since the issue is from 3.0.1 and I was unable to reproduce on master.

[Solarer]

Draft for a) : Mouse-Over

I am only considering both filemanager layouts here, it has to work differently for culling.

Overall, I think that mouse over is a valuable shortcut because it saves you an additional mouse click per action. That being said, I don't think that mouse over should ever take priority over selection.

I drafted a few cases in which selection + mouse-over could interact ('change rating' is just an example):

• You selected some pictures to change rating and hover over an image by accident
• You selected some pictures to change rating and want to include another picture in that same action
• You selected some pictures to change rating and realise that you want to do some other (unrelated) action on another (unrelated) picture first. For example: set a color label on that one picture.

Scenario 1 is probably the most likely and the reason why we have so many open issues. In scenario 2, the additional picture could just be added to the selection. Scenario 3 is the only one in which the current implementation provides an advantage. But how often does that happen and I don't know a single filemanager that behaves that way. This makes this feature very unintuitive. To make things worse, if you hover over an image that has already been selected, the whole selection is chosen instead of the picture you hovered over. So in scenario 3 I would expect the user to apply the rating first and then deselect all pictures before dealing with the color rating. He then can use mouse-over or selection to change the color label.

PS: Some people might still want to disable mouse-over completely because they don't like it or deem it dangerous. I am not sure if that is still necessary if selection takes priority over mouse-over but that could be discussed as well.

[Solarer]

Draft for b) and c) : a change to culling

Now, this is not only about changing dt_view_get_images_to act_on but I also propose a change for culling in general.

Culling officially has two modes (fixed and dynamic) but to be honest with you, in reality there are 3 modes:

1. If you enter culling (fixed) with selecting 0 or 1 images, you can scroll though all pictures without limitation and if you select more picture after entering the mode, that does not change. So in this case culling (fixed) behaves very similar to the filemanager. (I use this mode all the time because I prefer to rate and reject pictures like this rather than the filemanager mode. This is also how Lightroom does it.)
2. If you enter culling (fixed) while having selected 2 or more pictures, you can only scroll through your selected pictures. If you select more pictures, you can scroll through these as well and if you deselect them, you cannot scroll to them anymore. This is very different from the first mode because you cannot use selections as you are used to since releasing your selection locks you in place.
3. Today's dynamic mode. This is the same as 2 with the only exception that you always see all selected pictures. You cannot enter this mode without selecting at least one picture.

My proposal is to make a real split between modes 1|2 and instead merge 2&3 because they already are more or less the same. The only difference between 2&3 is how many pictures are displayed. So today's dynamic mode (3) could simply become position '0' in the slider of mode 2 where you select how many pictures you want to see. So it could look like this: [dynamic, 1, 2, 3, ...].

The first culling mode could then behave exactly like todays filemanager including the ability to select a picture with a single mouse click and adding more pictures with a Ctrl-click. Following the same arguments as in my previous post, selection should take priority over mouse-over and mouse-over takes priority over active images (We did not have active images in filemanager). That would tackle #6625, #7254, #7805 and #8898

In the second culling mode, all relevant pictures are always selected. So the priority has to be hover > active >selected. (With active=selected for the dynamic setting).

Please let me know what you think. This is probably the most controversial topic and while typing this I realised that I have no idea what other people use the culling modes for. I always use the first culling mode for my initial selection, rarely use the second to compare 2 pictures and never use the third (dynamic) because I can't deal with having more than 4 pictures on the screen at once. If people use the culling modes for other things, that would break because of this proposal, please post that here.

[Solarer]

Draft for the rest

• In full preview, only the displayed image should be acted on - independent of what might have been selected in the background and independent of the mouse position.
• In darkroom, the priority should probably also be selected > mouse-over > active just like my suggestion for filemanager and the new culling. I am not 100% sure, though.
• Mouse and keyboard support in all modes: needs to be tested.

I hope all of this makes sense.

[AlicVB]

Lot of work, @Solarer. Thanks ! Some thoughts :

First : we need to ensure to avoid breaking any workflows. While offering multiple image_to_act_on algorithm can allow that easily, I fear that your proposal about culling may be way more difficult to handle or ends with a "spread everywhere" change, which will be very difficult to maintain.

Now about your ideas, some questions that are not handle here (or maybe I miss them) :

• which image if pressing "single" image shortcut (example 'd')
• how about multiple copy-paste (again with shortcuts) ?
• how about selection when entering full preview or darkroom ?
• is there a difference if the mouse is on filmstrip or in the main window, or outside ?

I'm not convinced about your culling proposal. Culling goal is to compare a set of similar images. It has some advanced features to do that (automatic positioning, zoom/pan, ...) While it can be used for other things too (like your workflow) we should keep the initial goal in mind ! for me, 1 and 2 are the same, except that for 2, we limit the set of images (possibly with non continuous images selection) which is handy ! (this also works for full preview) 3 is completely different (as you state). The main usecase is when you want to find quickly the best images of a set of similar images : you show them all at first, then reject the most obviously bad and so on until you have only one image.

I'm sorry if that sound too critical, it's just that I know pretty well this part of the code, and so exactly know what can break and where ;)