Darktable: 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.