Bug 385270

*** Bug 365277 has been marked as a duplicate of this bug. ***

*** Bug 401716 has been marked as a duplicate of this bug. ***

*** Bug 385834 has been marked as a duplicate of this bug. ***

A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-pa/-/merge_requests/58

This is not just annoying with the touchpad, it happens when scrolling with the scrollwheel of a mouse too.

This is actually something that Linus from Linus Tech Tips mentioned as something that's bothering him, it would be great to have this fixed anytime soon so he can show off to his viewers that KDE is actively improving and fixing things all the time with an example of his own experience :D

Good idea! I think I have a way to fix this that will avoid upsetting the small number of people who would otherwise complain that this broke their workflow: we only allow scrolling on a control to change its value when it's focused. Then you can focus a control to fine-tune its value with a scroll, but unfocused controls will ignore scroll events to avoid the conflict between "view scroll" and "change control values scroll".

A possibly relevant merge request was started @ https://invent.kde.org/frameworks/plasma-framework/-/merge_requests/350

This has been fixed by Noah Davis with https://invent.kde.org/frameworks/kirigami/-/commit/f6ca218607ff7e5d5066eb3224154c3256cb9516 in Frameworks 5.90 with Plasma 5.24.

The fix is as follows: Now when you scroll on a scrollable view, any controls on the view which handle scroll events (like the sliders here) will not start changing when the cursor passes over them. They will only respond to a scroll when the cursor *starts* over them, not when it just happens to pass over them because the view is scrolling. This fixes the annoyance described here while preserving the controls' ability to be modified by scrolling on them, giving us the best of both worlds. Thanks Noah!

This actually did NOT fix anything!
There MUST be a feature toggle / flag in settings that disables scroll manipulation completely, otherwise KDE Plasma is unsuable for most people.

There are too many everyday situations in KDE Plasma when you have a mouse over a "scrollable" element like a widget, combobox, or even browser tabs and you start scrolling and it messes up everything, often causing a real damage in system config by accident.
No one in the right mind would use scroll to cycle through browser tabs, to change volume from tray or change important combobox/selectbox options.

Switching from Windows to KDE Plasma distros is a pain because of this feature only. Everything else would be great, but the scroll utilization is just everywhere and make users think hard about their mouse position before they can start scrolling, decreasing productivity a lot.

If there's anyone really using the Plasma scroll options (1% of users?), there at least should be the feature toggle to enable/disable it globally.

Please don't re-open closed bugs because you don't like the resolution.

> No one in the right mind would use scroll to cycle through browser tabs, to change volume
> from tray or change important combobox/selectbox options.
Evidently you don't, but a lot of people do. UX design is often a balance between competing interests and use cases. The way this is now implemented is supposed to be just such a balance between the use cases of scrolling views and changing controls by scrolling. You shouldn't experience the issue anymore unless your cursor *begins* over a scrollable control when you scroll; the control should not be changed by a scroll when it happens to pass under the stationary cursor while the view is being scrolled.

If this isn't what you see, then it sounds like there is a bug, and I would encourage you to file a bug report about it.

If this is what you see but you don't like it, them I'm sorry to hear that and you have a few options:
1. Manually edit the files on disk for Plasma controls to set `wheelEnabled: false` on the controls that change when scrolled
2. Use a different desktop environment

(In reply to Nate Graham from comment #10)
> The way this is now implemented
> is supposed to be just such a balance between the use cases of scrolling
> views and changing controls by scrolling. You shouldn't experience the issue
> anymore unless your cursor *begins* over a scrollable control when you
> scroll; the control should not be changed by a scroll when it happens to
> pass under the stationary cursor while the view is being scrolled.
> 
> If this isn't what you see, then it sounds like there is a bug, and I would
> encourage you to file a bug report about it.
> 
> If this is what you see but you don't like it, them I'm sorry to hear that
> and you have a few options:
> 1. Manually edit the files on disk for Plasma controls to set `wheelEnabled:
> false` on the controls that change when scrolled
> 2. Use a different desktop environment

This is exactly the problem, because KDE Plasma is the only desktop environment that really makes sense on Linux, and the EXACT problem is when I begin scrolling when my cursor is over a scrollable element, then it does not scroll, but changes option.

If this is as simple as changing wheelEnabled to false, I see no argument why not update it globally to something like this pseudocode:
wheelEnabled: getConfig("wheelEnabled")

This will make everyone happy and make more users switch to KDE Plasma and Linux in general.

I don't think you realize how bad the actual behaviour is and your own opinion and lack of action makes a huge impact on the future of KDE Plasma market share.
Really, you don't know what you are doing. Seems Microsoft will always have better market share, because they know and understand UI/UX. They also didn't ever think that middle button as paste is a good idea.

You really need someone who knows UI/UX for real and consult your ideas. KDE Plasma should be for people, not for developers, because developers don't think like people.

Making it configurable only helps the people who know that it's configurable, care to configure it, and remember that they configured it.

If we made it configurable but left "change-on-scroll" enabled by default, then it wouldn't change for new users just switching, so your claim would still stand. Most people don't configure anything.

If we made it configurable but disabled it by default, this would have the effect of removing the feature for 99.99% of people because, again, most people never configure anything. And it would be quite annoying for the people who like this feature, most of whom would not know that it is configurable or where to configure it. And disabling this feature for views that aren't scrollable would be totally pointless since there is no problem there. The potential problem exists only in scrollable views; for non-scrollable views, it is a nice timer-saver. So making it configurable wouldn't really help there.

In the end, I think our compromise is a good one. It was actually conceptualized by a UX designer. So perhaps he's the one who knows what he's doing, and you should have more faith in our design process. :)

Anyway, I just wanted to give some explanation and am not really in the mood to argue, so this will be my last response.

I dont see, how adding some configuration makes KDE worse. 
Simple by default, powerful when needed. 

I do agree, that bat is hyperbolic and the issue not that gravitational, but I do agree, that adding the feature might help some people.
I also get caught in wonders, when I scroll down in eg Kate, and suddenly I find myself in tab number 7 instead the first one. 

This is highly confusing and definitely something, that the KDE promise of configurability aims to solve. 
I love more configurability, and all the arguments of Nate against it, basically speak against the very essence of KDE.

There needs to be no compromised, when a configuration can solve it. 
Configuration first, compromise second.