Hello Linux Community!

I'm reaching out to the community regarding an issue I've been experiencing with mouse wheel behavior on Linux desktop environments. This problem has been discussed in various forum posts over the past several years, and I'm hoping to gather insights and suggestions to find a solution.

The Issue:

When using the mouse wheel to scroll through windows, the scroll stops on drop-down menus and sliders, inadvertently changing settings in applications. This behavior has been persistent across different desktop environments, and I've come across numerous forum posts where users express similar concerns.

Existing Forum Posts:

I've come across several forum posts discussing this issue going back as far as 12 years. These are just some of them:

• https://gitlab.gnome.org/GNOME/gtk/-/issues/3092 (This is the only open issue and the most recent I have found. I made a recent comment here)
• https://gitlab.gnome.org/GNOME/gtk/-/issues/513
• https://gitlab.gnome.org/GNOME/gtk/-/issues/593
• https://www.reddit.com/r/kde/comment...roll_changing/
• https://forum.xfce.org/viewtopic.php?id=14278
• https://bugzilla.gnome.org/show_bug.cgi?id=760610
• https://stackoverflow.com/questions/...ing-focus-when
• https://superuser.com/questions/1814...roll-a-setting (this is my own post from a few months ago)

Seeking Solutions:

There doesn’t seem to be any window manger (or tweaks) setting that disables this for the many users who find it problematic. I’ve seen suggestions on modifying the code of GTK or QT, or apps created with them, but from what I understand, that would require building your own version of these toolkits/apps, which comes with its own headaches.

Feature Suggestion:

Would it be possible to just have a setting in the same area where the mouse focus settings are that is something like “Use mouse wheel to cycle through widget values”, or something similar? If there were an option in desktop environment settings to choose whether or not the mouse wheel should be used to modify values on sliders and list boxes, I think it would please a great many people including myself and dramatically improve our user experience. This option would help prevent unintended changes to critical settings and potentially help prevent data loss.

How You Can Help:

1. Share Your Experience: If you've encountered a similar issue or have successfully resolved it, please share your experience and any solutions you've found.
2. Suggest Workarounds: If you have specific workarounds that have worked for you, let's compile a list of effective methods.
3. Support the Feature Suggestion: If you agree with the feature suggestion, please express your support. The more voices we have, the greater the chance of this suggestion being considered.

Conclusion:

I just want to make clear that I’m not talking about doing away with using the mouse wheel to change widget settings, but I would like to make it optional via some sort of toggle. I think addressing this issue would contribute to creating a more user-friendly Linux desktop experience.

Thank you for your time and collaboration.

Best regards,
Edwin Saunders

This is an interesting question. Theoretically. I think you need to understand how the window management works, what's happening when you press a key or use your mouse (or any other input device).
X should first identify the app which is currently in focus, and send the event to it to handle it (obviously X can decide if the event should be forwarded to an app or managed by itself). The app now will decide what to do with the event, but basically it is quite similar. The active item (button, input field, scrollbar, whatever) should be identified, usually based on the focus and/or the location of the pointer and this item should decide what to do.
What you are speaking about is the process to identify the object which should manage the mouse wheel event. The problem is: during the scrolling the object pointed by the mouse will change, and X is not able to decide if the wheel event should be sent to the old or the new one. The simple solution is just to send the event to the "current" one (or probably to the nearest one which can really handle that event). And there is no good answer to the question: what's wrong with it?

2 members found this post helpful.

Thanks for your reply and the information. Since posting on couple forums, it's been brought to my attention that Windows has this behaviour as well. I think the only reason I am noticing it now that I'm using Linux is that the slider and drop down menus are bigger and more prevalent, thus requiring me to be more mindful of where my mouse pointer is while scrolling a settings pane. I'm used to clicking the drop down first before selecting an option and also clicking and dragging sliders rather than using the mouse wheel. I guess I'll just have to get used to it.

How to replicate, can you give a step-by-step example? What does "scroll through windows" even mean?