search

darktable-org / darktable

darktable is an open source photography workflow application and raw developer
https://www.darktable.org
GNU General Public License v3.0
9.8k stars 1.14k forks source link

Images to Act On - How Should It Work? #6025

Closed elstoc closed 5 months ago

elstoc commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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

elstoc commented 4 years ago

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

jobec commented 4 years ago

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 commented 4 years ago

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] commented 4 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

@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 commented 3 years ago

@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 commented 3 years ago

@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 commented 3 years ago

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 commented 3 years ago

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 :

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 :

Solarer commented 3 years ago

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 commented 3 years ago

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:

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 commented 3 years ago

@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 commented 3 years ago

@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 commented 3 years ago

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):

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 commented 3 years ago

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 commented 3 years ago

Draft for the rest

I hope all of this makes sense.

AlicVB commented 3 years ago

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) :

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 ;)

Solarer commented 3 years ago

Your input is much appreciated. Everybody is more versatile in a different area, so concerns should be raised by everyone until everything is covered. I totally forgot about one image shortcuts :(

Can you elaborate on "multiple copy-paste with shortcut"?

AlicVB commented 3 years ago

Can you elaborate on "multiple copy-paste with shortcut"?

basically, it's just "copy history from 1 image" followed immediately by "paste this to multiple images (the selection)" Where it becomes little more fun is when you want to allow this in darkroom with filmstrip... With current implementation, you hover the source image, copy then hover the selection and paste. It may be no so easy with the alternative... and I know peoples that use that all the time ! Again, I'm not sure everything can be covered with the new system (or in more complex ways). That's not a problem as soon as we continue to offer multiple alternatives, cleanly designed so we can maintain both !

Solarer commented 3 years ago

"copy history from 1 image" followed immediately by "paste this to multiple images (the selection)"

That would still work but you would need to hover over an image to copy its history first and then select your target images to paste. The other way around is not really natural. Think about a file manager. You would not lock in the paste destination first and then go back to select the pictures to copy. It works the other way around. Or do people use this to select some target pictures and then take some edits from here and some edits from there, basically combining edits from multiple pictures?

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.

That I cannot evaluate, since I am not too familiar with the code. But from my point of view, 3 is just a special case of 2 where number_of_active_images = number_of_selected_images. Automatic positioning, zoom/pan, ... behave completely identical in both modes. You can try it for yourself: Select ~12 images, enter culling (fixed) and increase the slider to a high number such as 16. Now you can switch back and forth between fixed and dynamic mode as you deselect picture after picture. Both modes behave identically 'dynamic'. Based on that, both pieces of code should be identical except for a single if clause that is needed for setting number_of_active_images = number_of_selected_images in mode 3. In mode 1 however, you can scroll past your selection, which is impossible in 2 and 3.

which image if pressing "single" image shortcut (example 'd')

I totally forgot that and you are right, an exception should be made for at least some of the shortcuts (maybe all). For example it should still be possible to switch to full screen with 'w' when I hover an image while a selection is active in case I need to check a picture. About 'd' I am not sure - but it could be done since it does not really 'break' anything if you hover an image by accident. Then again, if you select 1 picture and move your mouse by accident before hitting 'd', would you not expect your selected picture to be shown in the darkroom? :P

how about selection when entering full preview or darkroom ?

If you don't hover anything, first selected picture should be taken (maybe first active in culling mode). If you hover something, that's open for discussion. Could be either first selected picture or hovered picture. Either way the selection should be maintained.

is there a difference if the mouse is on filmstrip or in the main window, or outside ?

I would only differentiate between mouse-over or no mouse-over no matter where the picture is.

AlicVB commented 3 years ago

Think about a file manager.

would you not expect your selected picture to be shown in the darkroom? :P

No I wouldn't... because I don't refer at how filemanagers works when I use dt. That's certainly because I'm an very old user ;)

Or do people use this to select some target pictures and then take some edits from here and some edits from there, basically combining edits from multiple pictures?

yes, all the time, esp in other modes than filemanager : you do your selection in filemanager (clearly the only mode with zoomable when you can do that for real) then you go, for example in darkroom, do some editing and copy/paste it to the selection. Same apply for culling (but less frequently)

That I cannot evaluate, since I am not too familiar with the code. But from my point of view, 3 is just a special case of 2 where number_of_active_images = number_of_selected_images. Automatic positioning, zoom/pan, ... behave completely identical in both modes.

I know, that's my code (originally) :) in fact all culling and preview modes share the same code. What has been chosen (for all modes, not only culling) is to not differentiate based on the input selection, but on how it works. The selection (if present) is only here to limit the set of images (you can imagine that as a sub-collection) That has been done to get similar workflow when you want to traverse you whole selection and when you are only interested in a subset of it...

I would only differentiate between mouse-over or no mouse-over no matter where the picture is.

If I understand, that may have strange results : imagine you have a selection of 50 images, you are in culling with 2 images shown and you use whatever left panel lib to apply something... imho, user expect that the action will be done on the 2 main images... (not to speak if filmstrip is hidden)

Either way the selection should be maintained.

agreed, imho the selection should always stay, expect on intentional user action (ctrl-click, ctrl-a, ...)

Solarer commented 3 years ago

Thanks again for your feedback!

because I don't refer at how filemanagers works when I use dt

I was making that reference because of @RawConvert's comment from a few days ago which I find very reasonable:

about being consistent and intuitive, I'd say reasonable compatibility with your average file manager is a good goal.

------------

yes, all the time

But could it not be done in the opposite order? Let's say I have a bunch of pictures that are all similar. I would edit one of them, copy that image's history stack, go to filemanager, select all similar images and then paste. Of course, changes to dt_view_get_images_to act_on will require some people to adapt how they interact with pictures - especially those that have been around for a while and know how to utilize dt's little quirks. But if the new implementation only changes the order in which things are done but does not require a ton of extra clicks or button-presses while being more consistent and intuitive, then that is probably a step in the right direction.

you can imagine that as a sub-collection

I understand that and while I do not use it a lot, I see how valuable that is and I would not want to take that feature away. I would simply reorganize how you enter culling modes 1, 2 and 3 and help visualize in what mode you are currently in! At the moment, you can only choose between modes 2 and 3 via gui and you end up in mode 1 by accident if you did not have a selection when you wanted to enter mode 2. In the same manner you end up in mode 2 by accident if you had a selection while you wanted to enter mode 1. Visually, you can not differentiate whether you are in mode 1 or 2 - you need to scroll and check if you can scroll past your selection to tell the modes apart. Additionally, if you ended up in the wrong mode, there is no way to switch back. You need to leave culling, change your selection and then reenter culling. Hence I would split 1 and 2 to keep them visually apart and stop the accidental switches. And then optionally merge 3 as a special case of 2 so that we do not need more than five gui buttons for the modes. Functionality would stay the same.

imho, user expect that the action will be done on the 2 main images

I agree for modes 2 and 3 since you are working on a 'sub-collection' as you call it. Because of that you cannot use your selection anymore and that more or less turns your active images into your only way of 'selecting' pictures here. So in these modes, your actions should be applied to all active images. In mode 1 you are not limited to a 'sub-collection' and can select images as you like. Therefore I would prioritize selection over active here. That would probably solve the complaints about selection not working in culling for export/ratings/etc.

Best, Solarer

johnny-bit commented 3 years ago

There are voices from users about unintentional hovers, eg: https://www.reddit.com/r/DarkTable/comments/nijve1/preventing_tag_editing_on_hover/

Nilvus commented 3 years ago

Should be good to find a good way with that on so close this debate for 3.8.

RawConvert commented 3 years ago

@Nilvus , just curious why 3.8? Master is 3.5 at the moment I think, so 3.8 seems an awful long way away.

elstoc commented 3 years ago

@RawConvert: 3.6 is due to be released at the start of July. We're way past feature freeze now. 3.8 is Christmas.

Nilvus commented 3 years ago

@Nilvus , just curious why 3.8? Master is 3.5 at the moment I think, so 3.8 seems an awful long way away.

As @elstoc says. It's too late for 3.6.

Solarer commented 3 years ago

@RawConvert 3.7 will be skipped, so 3.8 is the next release. Will be a nice Christmas present :)

RawConvert commented 3 years ago

Ok! Best wishes devs for a good fix to this issue.

alxgoldstn commented 3 years ago

New user here... I find hover selection to be extremely unintuitive. Perhaps some software works like this, but it's not how any software I've ever used works. I actually thought it was a bug and was getting super frustrated with the program.

Side note: Honestly the UI in DT is probably it's biggest issue for conversion (because the rest of it is great.) I've been struggling with picking up DT and keep googling for other software because I keep finding it's way too difficult to use the software intuitively. Read reviews of it online and this is also the number 1 issue people mention.

Solarer commented 3 years ago

I also can't wait until we get started here but I think people are still busy with the release - so let's give them some time. In the meantime you can leave feedback to my draft if you want. I don't think that we have agreed on an approach yet and that needs to be done before the coding starts.

Solarer commented 3 years ago

@here Now that 3.6 is out and most urgent bugs seem to be fixed, should we have a second look at this and start working?

TurboGit commented 2 years ago

Moving to 4.0 but clearly would be nice to have a summary about what remains on this issue as it is long and convoluted.

Solarer commented 2 years ago

I don't think anything has been done yet so what remains is a draft coding and see how it feels like and then iterate until all cases are covered

ianhattendorf commented 2 years ago

I'd like to throw #10592 in for consideration

Expected behavior Able to copy history of RAW file while image grouping is enabled. Similar to how double-clicking a grouped image opens the RAW file or mousing over a grouped image shows the RAW info, I would expect history copy to copy the history of that RAW file.

Solarer commented 2 years ago

Hi @AlicVB, I was hoping to code something during the holidays and as in preparation for this I was looking into src/dtgtk/culling.c Can you explain to me some phrases in the comment block lines 888-902?

What is "first image" in line 891 What is "first" in line 892 ("first selected" is clear, but what is "first"?)

Maybe it will become clear to me once you explained it, but what do I need to do in darktable to reach the states described in lines 896 and 901?

Thank you!

AlicVB commented 2 years ago

I wonder who has done such incomprehensible comments :) So, let's try to remember... I would propose to change the comment to something like : 

/** HOW it works :
   *
   * first image to show :
   *  offset OR image_over OR first selected OR first image in thumbtable view OR -1
   *
   * "navigation only inside selection" state :
   *  culling dynamic mode                       => OFF
   *  first image is in selection AND selection length > 1 => ON
   *  otherwise                                  => OFF
   *
   * "selection following" state :
   *  culling dynamic mode                                    => OFF
   *  first image(s) == selection && selection is continuous  => ON
   */

is that better understandable ? I you still need some explanation, that mean the comments need further changes ;) otherwise I will propose a PR with that change.