-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[RFC] act on selection #18484
base: master
Are you sure you want to change the base?
[RFC] act on selection #18484
Conversation
this allow to know if we are in the case of an old darktablerc with a new "undefined" key
Some early testing with hover not active
When I first started darktable I was using my normal workflow (lots of hovering) to see what worked and what didn't. Not much worked and my first thought was how crippled darktable felt. Doing anything seemed to take way more effort, clicks, time, etc. Like act on hover or not, it is a feature and disabling it cripples darktable. If the default is to not have hover active, then we are distributing "crippled" software. I think the default should be hover enabled and if the user doesn't like it, then turn it off. |
Thanks for your quick test.
|
I'm not able to reproduce this one...
How are you doing this exactly. I've tried "ctrl-t", "alt-t" and specific shortcut assigned to the quicktag Lua script, but they all work on the selection, not the hovered image... |
I checked and for me it seems all to be working. Although - i am a pretty bad tester as my personal dt workflow as a user is very conservative / simple, rarely use culling, almost never lua so likely i didn't get cornercases or am not even aware of functionality. Read through the act_on code and it's readable even for someone not knowing that code :-) First read - in the caching functions you are using |
I had a collection with nothing selected and I entered full preview layout. I could rate and tag the single image shown. The Lua errors were about having no image, because we rely on the hovered image being there. I just need to add some checks to make sure there is an image before trying to do something with it. |
Then, in my implementation of the algo, it's fine : "active" image(s) is higher priority. I've done this because I think that in this specific layout (full preview, culling and darkroom) user will expect action to happen on the "main" images, contrary to "browsing" layout... |
I've added a "features now difficult/impossible to achieve" part in the main post to track "conceptual issues" with new algo that need more thought (read : I'm not sure how to fix them right) For 1. and 2. currently the "only" solution I've think of is to implement a sort of "culling selection" different from the "normal" one, that won't be saved anywhere. Note that this will require quite a lot of change (but that's possible)... |
db23ca5
to
285862e
Compare
In order to fix 1. and 2. last commit implement a very simple culling-specific selection :
That should allow a "click and shortcut" workflow... |
Well, changing the default for one or the other algo is just one line of code, so I would prefer to let the decision for later, once the new mode as been extensively tested and we are sure it's production ready. But you have pointed a missing change I've completely missed : the "no image" page should reflect the algorithm ! btw : last commit enhance a little the css by swapping the hover and the selected background for selection algo (as the selection becomes more important than hover) |
I've finally some time the next weeks to work again on dt.
Given the importance of the problem, here is a proposal for solving the long-awaited issue #16850
It's largely inspired from @Solarer work. Sadly I have failed to cleanly rebase his PR, and anyway, there was some changes to do on them.
act_on feature changes :
except for the image information panel, which works on hovered image like before
culling/preview changes :
Default value :
Code changes :
point to check/review :
features now difficult/impossible to achieve :
In culling dynamic mode rating a single image with keyboard is impossible : you'll always act on all the images. and you can't change the selection, as dynamic mode is based on this selection... The only solution is to use the rating buttons in the overlays...-> fixedIn culling fixed mode, same problem, but you can change the selection via filmstrip for example.-> fixedOf course everything here is debatable (RFC and Draft), and I'm ready to change lot of things here ;)
It would also be great, as mentioned in the issue, if someone can have a "deep" look at what the code is doing, etc. As we have seen here, it's not good that some features are dependent on just one person ! I'm obviously ready to help ;)
Last point : I've tested the new algo quite a lot the last days for testing, and I'm still not convinced... In my typical usage, I always need more movements/click to do actions (but converting old users to the new algo is not the goal !)