Change the default for mouse scrolling over panels #16869
Conversation
…l instead of working with widgets
|
Could we make this a preference? Almost all users are used to the current behavior, so if we change the default there's probably going to be a lot of surprised users. Maybe leave the default as is, and give a preference to change to the new setting?
No news is good news. People complain about things that don't work for them. They don't spend time talking about the things that do work for them, unless it's something new they just discovered. I suspect that here, as well as act on images, 10% hate it, 10% love it, and 80% don't care (until it unexpectedly changes). So, if we change the default unexpectedly, then 10% will be happy and 90% wont.
I think the act on images issue has this beat 😄 I think we need to come up with a procedure for changing default behavior. Changing the default behavior is being discussed in #16850 also, and we haven't figured it out there either. @TurboGit thoughts on how to change default behavior? |
This PR is just changing the default value for an existing preference. It won't impact existing users who are used to the default behaviour, since their selected preference (or the previous default) gets hard-coded into darktablerc as soon as they exit darktable the first time. For me scrolling to change values is much more important than scrolling the panels and I much prefer the current default, but as a long-standing user I can't comment on whether this alternative is better or not for new users |
|
I feel like a huge number of them must not know that a simple ctrl alt toggles the feature so you can set you most used variant and then ctrl alt for the other behaviour... at least that is what I do... so it seems like this is easily fixed... Also I am amazed how many people download DT and just start using it and never explore the preferences and take some time to (a) figure out what options are there and what they do and then run through from end to end to be sure all of those selections are set to suit them... |
If an existing user corrupts their darktablerc file, then the solution is delete it and let darktable create a new one. They go to use darktable and things don't work like they were because the defaults have changed, so now they think something else is wrong. Also there's the case where people generate new environments for testing and development. Every new environment will now have a setting they aren't used to or don't want. I'm one of those. I generate 3 - 5 new environments a week for testing, development, and playing. Lastly, how many people are we really talking about that have this problem? 30, 50, 100? How many users does darktable have? Thousands? So we are changing the default behavior because a few people have a problem and the majority don't? I don't think we should be changing default behavior unless it's completely non-functional. If we decide that we have no other choice than to change the default behavior, then I think we need to publicize it using every method we can think of so that users don't get unexpected behavior/results just because they built a new environment or generated a new darktablerc file. |
|
I agree. Do not change the default but provide notice of it and how to change. |
|
A high-profile oft-linked FAQ would probably solve some of these issues |
|
This is a fix, that doesn't have a problem to fix. People complain...., but no one has raised an issue with darktable. If they did raise an issue, then they would be told the keyboard shortcut or setting to modify to take care of their problem. This needs to be closed. |
It's well-known that only a tiny minority of users ever open a preferences dialog to look at what can be configured. Anyone who gets that far qualifies as a power user :). Because of this, good defaults are important. But dt also has over a decade with the existing defaults, so any changes become problematic with regard to long-time users. Perhaps we could just open the preferences dialog when starting without a darktablerc. As a nudge... But if we do that, we should put the "mouse wheel scrolls module side panel" preference in the "general" tab. |
|
This pull request 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 verify it has no conflicts with the master branch and rebase if needed. Mention it now if you need help or give permission to other people to finish your work. |
|
I'm all for a preference here, as both solutions have drawbacks. Now, just wondering how other software using a panel with widgets behave? What about Lr? |
ON1 photo raw scrolls panels. They use a bit of an oversized slider button and if you click it you can use the scroll on that control. Moving the mouse point off that sliders button releases the focus and panel scrolling is restored... So there is no need for a separate preference |
Lightroom scrolls panels. There is no preference that would select scrolling widgets, the mode corresponding to our default simply does not exist in Lr. In Lightroom, it is possible to control the value of a widget (slider), but only after we click on it, thereby setting the focus on it. This is the mode I was going to propose as a replacement for the our currently dangerous behavior of affecting a widget that accidentally gets under the mouse pointer. But I see that there is a lot of opposition, and I don't have the energy to convince the opponents that we have a big problem with the behavior of the interface. |
|
The current behavior has a click on the slider proper also setting its value - which can be useful if you want to make a big change: click for a rough setting, then scroll to refine. If we want to keep that behavior as part of a click-to-focus revamp, then we should have a click on the slider's label mean "just focus" while a click on the slider proper means "focus and set new value". |
|
I have noticed that using the color equalizer when you hover on a node it indicates as highlighted but still when you mouse wheel scroll you don't need to grab the focus it just works on the nearest node when you are in the graph. I think there are keyboard modifiers on that but why I mention this is that visual highlighting of the node would be what you would see in ON1 and only then would the scollwheel work the slider. Otherwise it scrolls panels... So it would seem we have code in DT that could indicate focus within a slider and therefore give a potential visible cue for slider action |
|
On the other hand we do advertise the no-click workflow, which is exactly what is supported for all widgets, hover a slider scroll and the change is made. Having to click to select a slider will break the no-click workflow and will slow down users (at least me). |
|
Ya it would be a change and seen by some as better and others as not... for me I have this issue often that the focus is too broad as our sliders are so close in many modules that sometimes when I mouse wheel scroll I move the slider above or below. I wonder if it could be left as is but introduce some visual cue that indicates which slider has the focus for scrolling... maybe there is a padding or other adjustement I am just not aware of... |
|
As a new user of Darktable I feel like there are hundreds of these little papercuts. Idk if the functionality exists in Darktable (or if that is what you discussed above) but other opensource apps (e.g. Godot) sometimes change these default settings only for new users (projects), not existing ones. That way people who know scrolling changes the values of a slider will still have the workflow they're used to and new users will find a less steep first-time experience. |
|
This pull request 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 verify it has no conflicts with the master branch and rebase if needed. Mention it now if you need help or give permission to other people to finish your work. |
If you have to name one feature that annoys users in darktable the most, it's most likely the default change of widget values when scrolling with the mouse over the panels.
I hear complaints about this in feedback from members of the local photo community, I read them in comments on YouTube and various forums. I haven't seen any user feedback that they like the current default.
In addition, user troubleshooting sometimes boils down to an incorrect parameter in a module that the user claims he did not intentionally change. This is not an uncommon situation in my experience when I have helped solve a user problem. Obviously, in such cases, the reason was a change in the value of the widget by scrolling the mouse, which the user simply did not notice.