Conversation
There was a problem hiding this comment.
Thanks! This works well.
And here is the motivating use case behind my bug report: I have two similar photos, but I need to edit them before I can be sure which one I want to cull. After sharpening image X in darkroom, I decide to immediately cull image Y. I select Y on the filmstrip. (Unbeknownst to me, X is also automatically selected.) I press r to reject it. Result: X and Y are both rejected. I don't notice and later, I cull them both.
|
Let's not do this again... 😞 EDIT: as @anoderay pointed out in the issue, this has a long history. |
wpferguson
added
controversial
This looks even worst to me as the currently edited image in darkroom is not selected anymore. And so a paste won't apply to it. |
@wpferguson I understand your emotional reaction in relation to the past discussions but do you have functional concerns against my proposal? I actually don't see the benefit of forcing the selection of the active image when single-clicking on another image in the darkroom. I am happy to learn what I am overlooking.
@TurboGit Are you sure? From my testing that is not what I encountered. 1.) When entering darkroom the active image is still selected. But when clicking another image it is deselected. Screencast:
Bildschirmaufnahme_20260915_213237.webm |
|
To further my argument: I just noticed, that with my lua-scripted shortcut to reject+move to the next image the currently active image loses the "selected" status. Whatever the reason for that is. Rejecting and hitting space should be the same set of actions and doesn't lose "selected" status? I have never experienced any off behaviour even though I must have worked on hundreds of images that were "not selected". |
Because you had a filter active (images rated ?) then you rejected the image which removed it from the filter. The image in darkroom doesn't have to be selected to be developed.
You're wanting to change the DEFAULT behavior of darktable, which affects the whole user base, because you want it to work in a way that suits you. My concern is that you don't fully understand how darktable works, so you're trying to make it work the way you think (IYO) it should which isn't necessarily correct. Historically, to become a developer required a fairly in depth knowledge of darktable and how it worked. With AI that bar has disappeared and know it's possible for anyone with an LLM to decide that darktable doesn't work the way they think it should and so they want to change it. People are in such a hurry to change it that they never ask and answer the question, "Why is it this way?". Anytime I go to make a change, that's my first question because a lot of the time I find something else tied to it that would have a ripple effect. |
This is not about my workflow: I tried to find out and propse a fix for the failure mode described by @lefth in #22277. The possibility for accidentally rejecting images (which may go unnoticed if filtering for non-rejected images is enabled), also described above, is not good. And I truly don't understand why single-clicking an inactive image in darkrooms filmstrip should also (impercievably to the user) select the currently open image. I did my homework before opening this PR and did ask myself "Why is it this way?":
I have now also checked which PR introduced the line I am proposing to change (I should have done that before, I admit that). #17568 opened by @TurboGit. The PR reads:
But selecting a single image is not what is happening right now. When single-clicking a non-open image two images are selected. I am happy to be convinced that my proposal is a bad idea. But as long as I am not, I feel compelled to make a case for this change. And because I feel like I have to address the part of your comment that to me feels kinda ad-hominem: I have basic programming knowledge. I enjoy understanding technical challenges. I am one of the guys taking care of the docs now so I am interested in exactly and deeply understanding the UI and UX of darktable. And I 100% understand your concerns about code-bloat, unmaintainable code and the intense influx of new features and modules you voiced in #22294. And I share those concerns. And you are right: I probably do lack the technical knowledge to see off the top of my head whether a change may have ripple effects down the line. But I cannot see how this porposal bloats the code or affects maintainability or has anything to do with AI-Coding beyond the fact that I had claude help me understand the current setup and how to change it. AI disclaimer because I realize that this post may look Ai-lish: Every single word of this comment is my own. |
Why not just change the theming so that the user has feedback about what is selected? If you change the behavior then you just have more confused people if there's still no feedback. So maybe we change the feedback so users know and then if it's still an issue we look at changing how selection works. |
I agree that more feedback on what is selected and what is not makes sense. But this aspect is not an argument against this PR / for the present behavior in my opinion. I experimented with various css tweaks before. The dashed borders demonstrated by @lefth in his issue would be an obvious choice but are too visually busy IMHO. A slim white border somewhat works but is very hard to see for bright images. 
The small golden border is the one that seems least annoying to me but somewhat goes against the coloring paradigm of of the UI and also may be confusing in combination with the grouping-borders. Maybe something like one of these (hacked together in gimp)? 
|
|
I agree with the OP, it's a problematic behavior that has lead me to change the rating of the open image by mistake multiple times. For example, I want to change the rating of a group of images while editing my current image, I select them, press rating, and my open image is gone too. Perhaps theming change is a good way to address it, but as it is right now it's pretty confusing.
Exactly. This is what I do as well and I have to constantly change the filter to recover the image I am currently editing. -- I understand the argument to not change default behavior, but if the default behavior is problematic, what is the issue? Btw, just recently default behavior was changed, now I can't change to QAP without first closing crop, or any pickers I may have selected, slowing my workflow, and I didn't see anyone complaining about this? It seems to me like default behavior can only be changed if it comes from maintainers and not outside contributors. |
TL;DR When 2 darktable developers with 10+ years of darktable development experience each tell you that you;re solution is wrong, it's wrong. The problem: OP's statement : Depending on how I create a selection (not including the current image), the current image will or will not be automatically added to the selection. This behavior is unexpected and has resulted in the current image being rated unexpectedly. Meaning : I need to know how selection works in order to understand what is selected. The proposed solution: Cripple the rules of selection so that I know what is selected. Meaning : I need to to know how selection works in order to understand what is selected. If the meaning of the problem is the same as the meaning of the solution either you don't have a problem or you don't understand the problem. The REAL PROBLEM: When you open an image in darkroom the opened image has an arrow pointing to it and the overlay is highlighted indicating that it's selected. It's possible to create a selection that deselects the opened image. When that happens the highlight around the opened image is still bright indicating to the user that it's selected. The REAL SOLUTION Have the current darkroom image highlight only show as highlighted when it's selected. Why this solution works The user doesn't have to understand how selection works to SEE what is selected. In addition, having the selection highlight working correctly helps the user make selections because the feedback is accurate. |
Your outlined train of thought assume the current rules are the right ones and doesn't allow for asking whether the current setup could be improved.
This proposal can hardly be called "crippling". The functional difference is: Acting on a selection of inactive images from the filmstrip no longer automatically includes the open image, unless it is actively selected, too. That's how lighttable works, and addresses the cause behind the accidental ratings/rejects reported by @lefth and @hatsnp. I don't think this change is a drawback. I am eager to learn what I am overlooking. The manual doesn't describe the current behavior either:
"click on [..] a different image on the filmstrip with your mouse in order to act on it [...] without changing the image being processed" - that is not what is happening currently, because rating, pasting etc. will apply to both the single-clicked, inactive image and the active image.
Yes this is an important part of the solution. But e.g. if you scroll your active image out of the viewport to select/act on another image you just have to know how it works (and that it is different from lighttable and the conventions in every file explorer program I know). Do you have an opinion on what we could do to improve selection-visibility in the filmstrip? IMHO the golden border directly around the thumbnail-image is the most visible/pleasant solution. |
|
As this sadly isn't finding any traction I will close this now. |
5 participants
Addresses #22277
This may be controversial as selection (and mainly hovering behaviour) has been discussed extensively before. I am interested what you guys have to say.
Currently single-click selection in darkroom is different from lighttable: Single clicking a not-currently-open image ALSO selects the active image without any indication in the UI other then the counter of selected images being "two". This leads to surprising behaviours - exacerbated by the fact that the the current theming makes is impossible to see whether the active image is selected or not. See this issue.
This PR proposes to change the selection behavior: Single clicking a currently-not-open image selects the clicked image only, deselecting the active image if it has been selected before. This brings the darkrooms selection behavior in line with the way it works in the lighttable and as also outlined by @TurboGit in a discussion before.