STEPS TO REPRODUCE 1. Right click in the up arrow from the system tray > Configure system tray > Entries. 2. Place the mouse on any dropdown (don't open it) and scroll the mouse. OBSERVED RESULT The options will change. This can cause inadvertently changes that may lead the user into a bad state. For example, a user change some option just for the battery icon, but at some point the he/she "scrolled" the mouse on the Audio Volume dropdown menu. After hitting the apply button, the two options will be applied. EXPECTED RESULT/PROPOSED Changing the options through the mouse scroll should only be possible after opening the dropdown menu.
The example I gave might be simple, but this happens throughout the entire shell and applications. Really sensitive settings can be changed without the user noticing. I don't know if it's a Qt thing.
It is a Qt thing. Some people like it, others don't. We are working on a way to make the control only react to a scroll when you actually scroll while the cursor is deliberately over it, rather then when you scroll the view and the control happens to move under your cursor. However I submitted a MR to make this happen only when the control itself is focused: https://invent.kde.org/frameworks/qqc2-desktop-style/-/merge_requests/99 That became controversial though, so I don't know if it will be merged. Keeping this open to see how the discussion there shakes out.
Whoops, my bug report is a duplicate of https://bugs.kde.org/show_bug.cgi?id=399324
Not exactly; It's the same issue, but this bug report tracks fixing it in the qqc2-desktop-style, which is used for QtQuick apps. Bug 399324 tracks fixing it for QtWidgets apps. The different user interface frameworks require different fixes in different places.
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!
Wow, incredible work!