Images To Act On compendium - how it works, how SHOULD it work?, how it suprises users

[ralfbrown]

Collecting various related threads/issues into one place.

The big discussion of how Act On should work:

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

Surprising users since 2009 :)

14462 Selection not working correctly in filmstrip

14840 Mouse position unexpectedly changes selected image

15780 Mouse hover focus image change on row-change

16116 Pasting settings to multiple images doesn't work reliably

16358 Export function follows active image

[wpferguson]

How about instead of discussing everyone's opinion of what is right or wrong with images to act on, we compile of list of mouse workflows. Once we have a list (or maybe we build a survey and do it that way) then we can focus on how to make those workflows work. It's much easier to implement a workflow than to change an opinion :).

My mouse workflows

lighttable

• hover over images to and reject/rate. Scroll through the lighttable with the mouse wheel.
• copy/paste history - clilck to select the image to copy from, click selective oppy in the history module, click what I want to copy, choose invert select in the select module, then paste in the history module.
• create style - select the image to build from, then click create in the style module
• apply style - usually it's select all images, then select the style from the style module and apply. Sometimes I select a set of images by clicking, then use the style module to select and apply
• image_time script - I often shoot with 2 bodies, so I trigger a shot simultaneously with both bodies and use that to synchronize the image times. I select the simultaneous shots by clicking, then go to the module to determine the time difference, then sort by filename and pick one body's images by click, shift click and apply the correction.
• group lua script. Hove over any image in a group and use a shortcut to only display that group of images in lighttable. Use the shortcut again to return to all the images.

darkroom

• i use the histogram and scroll wheel to adjust exposure
• I try and use lua-scripts and keyboard shortcuts to eliminate as many clicks as possible, resulting in only taking seconds per image instead of minutes per image to process.
• most of my mouse usage in darkroom is in the modules or applying/adjusting a mask.

filmstrip - don't use, rather have the space

timeline - don't use, rather have the space

map view - seldom use so I really don't have a workflow

[Solarer]

The issue is:

• If you have a workflow, that can be done by hovering OR selecting images with a click

and

• you selected some images while hovering a DIFFERENT image

... what should happen? On which images should darktable act on?

Note that this can happen by choice because a user expects one to have higher priority than the other (some say selection should be higher, some argue for hovering). Or by accident because of a mouse slip. Pair that with the fact that not everyone knows that you CAN work with darktable by hovering and you end up with confused users and bug reports.

[elstoc]

I think a good general principle is "hover to see information", "click to make changes"

[luator]

I think it get's problematic mostly with more keyboard-based workflows. I don't use the mouse so much, but rather rely on keyboard shortcuts for things like rating, applying colour labels, exporting, etc. In that case the mouse cursor can randomly be anywhere, potentially hovering above some other image.

Pair that with the fact that not everyone knows that you CAN work with darktable

This is the main issue in my opinion. That behaviour of darktable is rather unusual, so new users won't expect it. At least for me it took quite a while to learn about this feature by coincidence. Before that I was often confused why my actions where sometimes applied to some random image instead of the one I selected.

[elstoc]

Agreed. Image processing is hard enough. Darktable does things that even other image processing software doesn't do (scene-referred workflow, for example) and there is therefore already a big learning curve, without making "standard" stuff unpredictable as well.

We should only move away from established/known UI patterns if there's a really good reason, and there are many cases in darktable where we establish new patterns with no real need for having done so, making for a poorer UX, and putting off users before they've even started learning how to process images.

[TurboGit]

Maybe also an opportunity to discuss the filmstrip handling. To me we should also be back on something more common:

• click to select a single image
• ctrl+click to add an image to the selection
• shift+click to add a range of image to selection
• double click to edit the picture on darkroom

So, exactly what we do on the lighttable.

[wpferguson]

So far we've established that people wont/don't/can't read the documentation (though I use it a lot, thanks @elstoc, @paperdigits, and others).

I think that "standard" is in the eyes of the beholder. For instance, highlighted = selected in "standard", but when users mouse over an image and it's highlighted (because it's selected) they don't respond to the visual cue.

Why do users use keyboard shortcuts? Because, it's faster than clicking. So why would you do something because it's faster (keyboard shortcuts) only to hamper it by doing something that's slower (clicking). Perhaps it's a marketing issue. We should advertise the "no-click" workflow because it's the fastest way to deal with images.

Finally filmstrip. I agree with @TurboGit . I used to use filmstrip, but only for navigation until my workflow evolved enough to not need it. I didn't know you could copy and paste to it until someone raised an issue. Maybe we open an RFC for how users want to use filmstrip?

My thoughts on act on images:

• make it an option whether it's on or off - I can live with that
• make the option off by default - I can live with that
• remove it - I'm against that. It would severely impact my workflow as well as breaking lua-scripts that rely on that behavior.

[luator]

So far we've established that people wont/don't/can't read the documentation

I think the "it's written in the documentation" argument is a bit flawed for things like this. You can't reasonably expect users to read the whole documentation from top to bottom for every application they use. Of course, I check the documentation if I have a question, e.g. something like "how does this module work?". But "how do I select an item to operate on?" is usually not a question I have, because it basically works the same everywhere else and it isn't directly obvious that darktable behaves differently in that regard.

I guess adding an option would indeed be the best way to make everyone happy. Of course assuming it can be done without adding disproportionate complexity to the code (I'm just a user, so I can't comment on that aspect).

[wpferguson]

I think the "it's written in the documentation" argument is a bit flawed for things like this.

Wouldn't it be reasonable to think that when you encounter the images to act on behavior and it's unexpected, that you would go to the documentation to figure out why it behaved that way? If you look at the issues above, it doesn't appear that happened.

[elstoc]

when you encounter the images to act on behavior and it's unexpected, that you would go to the documentation to figure out why it behaved that way

Unless what you did was accidentally delete the wrong file from the file system, in which case you curse first

[rekcodocker]

I think the "it's written in the documentation" argument is a bit flawed for things like this.

Wouldn't it be reasonable to think that when you encounter the images to act on behavior and it's unexpected, that you would go to the documentation to figure out why it behaved that way? If you look at the issues above, it doesn't appear that happened.

Consider this, a user interface can behave in two ways:

1. complex behaviour which can do everything but works different from all other software. After you write the software you must write documentation to explain in text what the concepts are and how it works. And the users have to read all of that before they can use it.

2. or you can skip the above and have the user interface behave like people expect, because that is how all software behaves and it has become intuitive.

Yes, when it comes to the complex inner workings of what the software is supposed to do, manual may be required. But when it comes to basic stuff like selecting, double clicking, activating, raising - there are patterns that people know and there is no reason to change this - unless you want to alienate new potential users of course. 'it was hard to write so it should be hard to understand' is not a good principle.

[elstoc]

Having hover-to-select as an optional thing and disabled by default seems like the best proposal to manage this. People who find it useful for their workflow enable it knowing the pitfalls. New users don't foot-shoot by accident.

[wpferguson]

Yesterday when I talked about the no-click interface and said maybe it was a marketing issue it stuck in my head and my brain has been working overtime on it picking it apart trying to figure it out. While I still believe we have a marketing issue, I think the deeper problem is that we may have a paradigm issue.

When Adobe developed Lightroom they were trying to figure out what kind of interface to put on it and picked the office application paradigm. Click to select, shift click the extend the collection, copy and paste from a menu but have keyboard shortcuts. Create a selection then apply an action to it. Just like a word processor.....

The other raw processors that have come after have adopted the same conventions. Lightroom works, is popular, successful, etc. so it's a pretty safe choice.

But....

We're photographers. We put a camera to our eye. Our eye picks a subject and our hands move the camera to keep the subject in sight with no conscious thought. We manipulate zoom rings to frame the subject, back button focus, shutter release, etc with our fingers continuously, then when we have the image we want we shoot. So, we have the point and shoot paradigm. It's very fast and works well especially when shooting sports. Imagine if we had to click to select the subject, shift click to get the person next to the subject, select from a menu to focus......

What if we apply the point and shoot paradigm to darktable, i.e. darktable meets first person shooter. I look at the image I want to change, my hand moves the mouse cursor to where my eyes are looking, and I hit a keyboard shortcut to change the image. Using this paradigm, hover to focus makes perfect sense and how it works is easily understood.

So what we have is 3 workflows:

• all click workflow - click to select, shift click to extend, go into a module or menu to perform an action. No unintended consequences,
• no click workflow - the point and shoot paradigm. No unintended consequences unless your hand/eye coordination is off
• some click workfow - the wordprocessor paradigm. The all click workflow with keyboard shortcuts. This has no unintended consequences as long as you remember to always hover over your selection.

[elstoc]

Sure we're photographers and we're happy with alternative workflows. But, to take an example, back-button focus isn't automatically enabled and you have to customise your camera to make use of it (I use hardly any of the default button assignments on my camera). It's one reason why I'm generally happy with the ability to customise things in darktable - I'm already used to using tech to make a nice smooth workflow for myself.

But if you bought a camera it would feel odd not to have both Auto-focus and Auto-exposure on the shutter half-press by default. Similarly, like it or not, almost all other software (photography and non-photography) has established some reasonable expectations in the user and we should use them by default if we can. If the user finds our optional alternative better, then that's great.

In terms of the "3 workflows" I worry that we might restrict ourselves a bit too much, or make the whole thing more confusing again, and need a list of what is or is not included in each workflow. Again a simple on/off switch that enables/disables using hover to do things is fine and clear.

I would maybe just change the behaviour around clicky selections vs hover, if I've already selected an image with a click and it's in the viewport, operate on that. If I've selected multiple images, regardless of whether they're in the viewport, operate on those. If neither of those is true, operate on the hovered image.

[wpferguson]

I would maybe just change the behaviour around clicky selections vs hover

I had that exact thought after I finished typing that last bit. It's playing out in my head right not to figure out if there's any drawbacks to it. I don't think so because if I had a selection and then hovered somewhere else to make a change the selection would still be affected.

As far as back button focus, I grew up in the days when you had to turn the ring on the lens and match the needles to get the exposure right :smile: It's just all magic now

The simplest solution for now, until we change something, is to always hover over your selection and that way you can't inadvertently select something else.

[elstoc]

The simplest solution for now, until we change something, is to always hover over your selection and that way you can't inadvertently select something else.

Well yes, of course here we're likely to be talking to people who have got used to the oddness

[Solarer]

I have a branch ready, that addresses the issues with the act on algorithm but it is not a straightforward fix. Selection and hover touch more areas than you would think - I even needed some changes to culling mode to get it work.

It has not been finished because I was too busy with family and my job, same for @AlicVB who needed to review and approve. I believe the only thing that is left to do is fix an issue with key bindings (and of course rebasing the outdated branch). I can offer to rebase the branch if someone else is willing to follow up with it...

I am still very busy and if the same is still true for AllicVB, we need some outside help for fixing and approving.

[wpferguson]

I thought I remembered someone working on this awhile ago and I remembered that it touched a lot of things.

What changes does your fix make?

EDIT: Never mind, I found it.

[AlicVB]

Same as @Solarer : I'm really busy with all sort of things and will not have time atm to work on this. If I remember correctly, the plan was :

• implement a new solution alongside the current one
• keep the current solution as default for current user
• make the new solution the default for new users (eventually after a test phase, as it's a critical part)

iirc, the more tricky parts were culling (mode detection on enter, and act-on once inside), and filmstrip (not sure @Solarer has even yet worked on this part)

Of course, I'm happy to discuss the details with anyone willing to take over!

[Solarer]

Yeah, we split the work into 2 PRs. First one to get the prerequisites out of the way in culling and the second to implement the act on algorithm. We got stuck at the end of the first one, but code for the second one does exist (mixed up in a huge PR, so I will need to extract the relevant code in a new PR) 1: #13278 2: #10728

[Solarer]

The main change is to change the priority from hover > selection to selection > hover. But hover can still be used for actions that do not make any changes (quick preview, view image meta data, copy edit history)

Who can take over from @AlicVB the reviewer role and who can assist me in finalizing the code? I can get the functionality done, but I don't have time for multiple review rounds and cleaning up the edges.

[wpferguson]

Is this still the plan?

• implement a new solution alongside the current one
• keep the current solution as default for current use
• make the new solution the default for new users (eventually after a test phase, as it's a critical part)

I just used gitk on act_on.c and the only person that's actually worked on the act_on part is @AlicVB. A few people have touched it to do some maintenance related to other PRs.

I just looked at act_on.c. It's only 337 lines of code. The real problem is at least 19 other pieces of code call this which tells me that the toughest part is going to be understanding/testing all the interactions (and trying not to break anything).

I'm willing to take on the role of intermediate reviewer. I'd still like @AlicVB to give the final blessing, but I can look at code, test, and help figure out issues.

I need a week to finish up what I'm working on and another week to dig through the code and interactions and try and figure it out (fprintf is my friend). I don't know the culling code either, so I may need a little while to figure it out too.'

[Solarer]

Is this still the plan?

implement a new solution alongside the current one keep the current solution as default for current use make the new solution the default for new users (eventually after a test phase, as it's a critical part)

Yes, except that we should change it for everyone to a 'less unusual' behavior and give those who really want to go back to the old ways an option to do that. After testing of course

[AlicVB]

@wpferguson : thanks for your proposal. I'll take the time needed to help and review !

@Solarer : As said earlier, I'm quite reluctant to change this for "old" users : I know a lot of them that are used to the actual behavior and will be quite surprised by such change, esp. as it's not "visual" and touch a important part of the UI. imho that would be bad to give them the impression that "something" as broken their workflow until they understand that there's an option to change in the prefs... ... But that's a detail compared to the rest of the work ! So we could/should discuss this point later

[wpferguson]

@Solarer I agree with @AlicVB.

After spending a lot of thought on changing default behaviors, here's the 3 issues I have.

If a long time user corrupts their darktablerc file then they delete it and start darktable to recreate it. If, when the start darktable, darktable no longer behaves the way it used to, then the user is left thinking they have a darktable issue and that's what might have corrupted their darktablerc file.

I spin up new darktable environments (code, images, executables, scripts, directory structure) for testing, development and playing. I usually spin up 3 - 5 per week. It would get awfully old, awfully quick, that darktable keeps coming up in the wrong configuration

If we go through all the issues attached above, how may actual users cared enough to open an issue or comment? 20, 30 40? How many users of darktable are there? Thousands? I think 10% of users hate this, 10% love it, and 80% aren't bothered by it or don't care. If we fix it and give the user an option to make that the default, then the 10% that hate it are happy because their problem is fixed, and the other 90% are happy because everything still works the same. If we fix it and change the default, then the 10% that hated it are happy, the 10% who love it are mad, the the 80% are upset because darktable doesn't work they way they are used to. So the choice is piss off 90% of the people or not. Or, have 10% happy or 100% happy.

[elstoc]

If we go through all the issues attached above, how may actual users cared enough to open an issue or comment? 20, 30 40? How many users of darktable are there? Thousands?

An important corollary question is "how many people are aware that there's a place they can go where they are permitted to suggest changes to the application, and where those suggestions will actually be considered by the devs"? I'd bet that a lot of users are used to the commercial model where you get what you pay for and live with its shortcomings, with fingers crossed that things are fixed/changed in the next release.

Remember we're all here people who are used to working with FOSS, and we're (on github) largely living in a very small echo chamber where only about a couple of dozen people actually participate in any of these discussions.

Anyway, you're basically arguing never to change darktable.

[Solarer]

Honestly, deciding that is the very last step, after completing testing. We have not yet found a volunteer to help with the coding yet...

I just think that the people who want to keep the current implementation can at least go looking for it if it has been changed. They can read about it in the change log or create a ticket asking for it.

The other group might not realize that an alternative is available, thus they don't go looking for it. Especially when we think about people installing darktable 2 years in the future. They will not read old changelogs. How should the program behave out of the box? What setting is raising fewer questions and a better starting point?

Because of that I argue that the default should eventually be changed. But only after everything is running fine and has been tested.

For now we need someone helping with coding.

[wpferguson]

Help with coding what? The culling part of the act_on part? If I'm going to dig through the act_on part to understand it, then I can probably do the coding part too.

[wpferguson]

people installing darktable 2 years in the future

The same reasoning applies for old users that regenerate their darktablerc. The difference is that old users know how darktable is supposed to work for them. New users are still trying to figure out how darktable works. Perhaps we need a guided setup that helps new users configure darktable, or maybe just a simple are you a new user? question that if they answer yes to we turn off hover by default.

[wpferguson]

@Solarer, @AlicVB what are the code changes that are planned?

Is it extract the act_on behavior to common/act_on.c and then go through the culling and thumbtable code and replace the current code with calls to act_on?

[wpferguson]

15780 and #14840 are the same root cause. I know exactly what causes it and where it happens. And I don't have a clue how to fix it (yet) without completely breaking darktable.

As for the filmstrip issues, I really think we need a separate issue, how should filmstrip behave/be used?

My questions are:

• Should we carry a selection from lighttable into darkroom filmstrip or back from filmstrip to lighttable?
• If we are in darkroom and copying and pasting to/from the filmstrip, how do we determine the source and the target? i.,e. what if I want to copy from an image in the filmstrip and paste the the image in darkroom? Or, if I have an image selected in filmstrip and I'm in darkroom how do figure out which image to copy from if I don't look at where the mouse is?
• How should we select photos in the filmstrip? Should I throw away an existing selection (deselect) if a new image is selected?

[ralfbrown]

As for the filmstrip issues, I really think we need a separate issue, how should filmstrip behave/be used?

Agreed.

My questions are:

• Should we carry a selection from lighttable into darkroom filmstrip or back from filmstrip to lighttable?

YES YES YES

* If we are in darkroom and copying and pasting to/from the filmstrip, how do we determine the source and the target? i.,e. what if I want to copy from an image in the filmstrip and paste the the image in darkroom? Or, if I have an image selected in filmstrip and I'm in darkroom how do figure out which image to copy from if I don't look at where the mouse is?

Default source should definitely be the image in center view, since I think copies will mostly be of a just-changed edit to other images. For the less-common case of using a different image as source, I'm not sure there's any reasonable way better than making that image the one in center view first.

* How should we select photos in the filmstrip?  Should I throw away an existing selection (deselect) if a new image is selected?

While I'm used to hitting Ctrl-Shift-A all the time prior to changing selections, I think standard UI behavior would be preferable (as spelled out by Pascal upthread). In particular, I'd prefer double-click to change active images, as I'm currently more likely to unintentionally switch images with a single click - usually I meant to start a selection when that happens....

[Solarer]

Help with coding what?

I just need a second person who can react faster to change request than me and implement fixes in a reasonable time frame. Whenever @AlicVB found some time for a review, it took me up to 2 weeks until I found the time to work on it again. Then it took AlicVB 2 weeks to find time for a review. We regularly forgot what we talked about because too much time had passed.

what are the code changes that are planned?

First we need the change to culling described here Once that is merged, the act on algorithm can be adjusted. There will be a drop down setting to chose between the old or new implementation.

[wpferguson]

Can we all agree that mouse over image is not the same as image under mouse?

Mouse over image is when I move the mouse cursor over an image of my choosing.

Image under mouse is when the mouse is idle and the underlying group of images change so that new image appears under the mouse which triggers mouse over image changed.

This is the problem with #14840 and #15780.

[wpferguson]

@Solarer I read back up the comments from my question and found the PRs. I just finished reading through yours (discussion only) and I'm about to start on @AlicVB's.

I did start to wonder toward the end of the discussion if doing act on first might help with the culling since it seemed that part of @AlicVB 's issues were not being able to get the correct images into culling.

I'm good for time until mid July then I'll have to slow down some, but even then my response time should be no longer than a day or two.

[Solarer]

I did start to wonder toward the end of the discussion if doing act on first might help with the culling since it seemed that part of @AlicVB 's issues were not being able to get the correct images into culling.

I don't remember that issue. Can you send a link? The act on code has nothing to do with which images get selected or end up in culling. It only decides the priority if a selection and mouse hover happen at the same time.

For the same reason #14840 and #15780 are not an act on issue and can be tackled independently.

Thank you, a response time of a few days is perfectly fine 👍. We just need to make sure that we have the same understanding of the proposed solution. Did you understand the planned change to culling and why it is necessary? Feel free to ask if something is unclear.

[Solarer]

Can we all agree that mouse over image is not the same as image under mouse?

Yeah, but that is of no concern for the act on code. It only checks if an image is hovered over by the mouse. Whether the mouse was move to the image or the image moved to the mouse does not matter.

[jenshannoschwalm]

@elstoc wrote

I would maybe just change the behaviour around clicky selections vs hover, if I've already selected an image with a click and it's in the viewport, operate on that. If I've selected multiple images, regardless of whether they're in the viewport, operate on those. If neither of those is true, operate on the hovered image.

Using mouse, keyboard and loupedeck here.

If I carefully selected a number of images for some work I would not want to have that modified by any other way - here img under mouse.

I always feel I have to make sure... that is definitely slowing my workflow.

I love the hover concept for pace in all no-selection-done cases.

Maybe some extra strong visualized hovered image if not in selection would be a way. Red background ?

[AlicVB]

If I carefully selected a number of images for some work I would not want to have that modified by any other way - here img under mouse.

Lot of work as been done to ensure that point. Esp. when switching view/modes. The idea is to never void/change the selection except if the user explicitly decide it (clik on thumbnail, etc...) But the last part of your sentence makes me think that you refer to something else...

Maybe some extra strong visualized hovered image if not in selection would be a way. Red background ?

I love that idea : with the current behavior, emphasis the image which will be modified / act on : maybe some color border, like what we have for expanded groups ? That way we can handle the case of multiple images. That said, imho, that will not avoid the need to implement a different (more "usual") algorithm.

[Solarer]

I updated #13278. It is now up to date with master and the previous issue with not working shortcuts has been fixed.

@wpferguson and/or @AlicVB you can have a look.

Once this is through, work on the act-on algorithm can begin :+1:

[daturkel]

I'm happy to see this conversation happening—I personally find the "act on hovered item" behavior quite unexpected and it's caused me to rate the wrong image many times. I'm not familiar with the darktable codebase, but I am aware that the Ansel fork has allegedly changed this behavior, which may be helpful in determining a path forward for how to make the change. From the "transitioning from darktable to Ansel" page, describing behavior that has been changed in Ansel:

“Mouse over” event In lighttable, the “mouse over” event now does not select images for writing and possibly harmful operation (writing metadata, copying history stack, deleting/moving files, applying styles, rating, labelling, tagging etc.). These “mouse over” events trigger only safe read-only events in the metadata display module. Modules listening to “mouse over” Similarly, the modules like tagging, geotagging, etc. that reacted to the “mouse over” event (by updating their content) now only react to hard selection (click or key stroke). This saves many SQL requests to read metadata when moving the mouse in lighttable and improves responsiveness.

I searched the repo for a while but could not find the specific issue or PR which was related to this change, but presumably someone more familiar which files this involves should be able to find the relevant commits. My best guess is these three:

https://github.com/aurelienpierreeng/ansel/commit/425a969c7a92fcc0f2c6812ae0da87e70d946f68 https://github.com/aurelienpierreeng/ansel/commit/9d081d9c5cb85a284daf3432cc205fcfa4acb326 https://github.com/aurelienpierreeng/ansel/commit/35d9646d46d2e90de385aaf27b6e82ed17dbbcdb

[Solarer]

Thanks a lot! I am curious about the increase in responsiveness and will do a code comparison with my draft once the first PR is through.

[wpferguson]

@daturkel if you embrace the act on hover, your workflow speeds up tremendously. I can rate 10 images hovering in the time it takes to rate 1 selecting.

Another thought on changing the default behavior:

I'm a new user. I install darktable. I go through the settings and disable act on hover. I will never touch that setting again. If I upgrade, I'll install over the top of the existing and retain my settings.

If we make the default act on hover disabled we have saved a new user 1 click.

Now for the far other end of users, me. I use, develop, test, play, build releases, etc. I have 26 (4.8.0 , master, 4.7, 4.5, 6 PR/issue testing, 16 development) instances of darktable installed right now. I also have several VMs (24.04, Win 11, 2 Win 10, Win 7) with multiple instances of darktable installed. I normally create 2 - 3 instances a week to test PRs/Issues/ideas. If the default value of act on hover is off, then I have to change it for each instance (35 - 40). Then each time I spin up a new environment I have to go in and "fix" it so it "works" correctly (for me).

As I've said before, 10 - 20 percent love it, 10 - 20 percent hate it, and 60 - 80 percent don't care. Give the 10 - 20 percent that hate it a solution (i.e. turn it off) and everyone will be happy or not care.

[daturkel]

@wpferguson I understand that there is baggage around changing default behavior, so I'm not going to die on that hill (even if I think act on hover is more surprising). I just think there should be an option to disable the behavior for those who find it unintuitive (like myself and others in this thread).

(Additionally, you may be conflating two dichotomies: "installs once vs installs many times" and "wants act-on-hover vs doesn't." There is no reason to believe that, generally, people who install many times are more likely to want the default to be act-on-hover. I don't see why there would be any correlation one way or the other, so you're likely to always annoy some frequent re-installers whenever you choose a default.)

edit: whoops, I posted basically simultaneously with @Solarer , so there's some overlap between our comments. Not trying to pile on or be redundant.

[Solarer]

edit: @daturkel yeah, same for me. You posted first and I did not see it in time, sorry

You could also argue that ~98% of all users will just upgrade their darktable and keep their old configuration. So whether they decide to turn hover on or off, they only need to do it once.

The only people that install a fresh darktable regularly is us devs that need to test code and in that situation, we are not in a user role. You probably also have a dt installation somewhere that you do not wipe but just upgrade. That is your user environment.

I understand that you are already spending a lot of time and effort spinning up those versions and that each little increment multiplies across all instances. May I suggest something that might help you with that already today? If you create a 'dev' copy of your darktable config and store it somewhere where it is not trashed, you could point your test deployments to that central config file and reuse it.

[Solarer]

But as I said before, first we need the code to work ;)

[wpferguson]

I just think there should be an option to disable the behavior

I agree

you're likely to always annoy some frequent re-installers whenever you choose a default.

Only if you change it because they are already used to the existing default.

we are not in a user role

But we are. When I test the first part of the test is use the steps to recreate, then verify the fix works. The next step is to use darktable and make sure nothing else got broken from the fix.

[parafin]

You can have a darktablerc file with just one line enabling the focus-under-mouse and copy it to all new environments. Since you probably use some scripts for development automation, adding just one more non-manual step won’t matter to you.

[AlicVB]

tbh, as @Solarer said, the question of the default behavior, is not the actual one : We first need to have a "really" working alternative :

1. That allow to have the possibility to keep the actual one without any change
2. That is 1:1 feature wise with the actual solution
3. That is stable enough to be released (this a very sensible area)

For that we need to have coders, reviewers, etc, and it's the main pb here atm (sadly I'm part of the problem)

[github-actions[bot]]

This issue has been marked as stale due to inactivity for the last 60 days. It will be automatically closed in 300 days if no update occurs. Please check if the master branch has fixed it and report again or close the issue.