Disable "scroll page to change a random value" behavior #uxquirk

[vkhatab]

Boom, I changed my Refresh rate to 50hz just by scrolling the display setting page. (and I didn’t even scroll from the dropdown control, the page actually moved.) Just need to hit “Apply” and I’m good to go !

If you’re scrolling a kde app and pass by any kind of dropdown, list, tab etc. the scroll action can very easily be passed down to the control, changing its value.

In addition to being an unintended sideffect of simply scrolling a page, this behavior can easily cause accidental changes to settings. I’ve had this happen to me on many times. Given how ginormous KDE settings are it’s all too easy to scroll past a random control and do something you never intended.

If somebody wants to change the value of a dropdown, they should click on it and select the value they want. I doubt anyone intentionally changes dropdown values by scrolling - and if they do they shouldn’t.

I would disable scrolling input entirely for the following controls: tabs, dropdowns, spinboxes, sliders and addressbars (see dolphin). I would certainly disable it for any controls are located in scrolling views. I know some browsers have scrolling behavior for tabs, which is also a bad idea, but at least they have a well defined tab area. QT apps can have tabs all over the place, including in scrolling views and the risk of changing tabs by accident is that much greater.

With regard to this, Gnome’s UX is instructive and a model to follow: scrolling is only used for the occasional volume or other dial and of course for actual scrolling, without any random sideffects.

NB: (I’ll be using the #uxquirk tag to here document some UX/UI issues on KDE/QT that seem like deviations from “best practices” as seen on other platforms. )

[vkhatab]

@ngraham I’ve got a bunch more of these KDE-specific quirks but it seems almost too many to list and probably too many to ever really fix, not without having a design guy whose full time job it is to iron these things out in accordance with “best practices,” and ultimately outline a comprehensive redesign where such issues do not arise, rather than dealing with everything on an ad hock basis.

Should I keep going?

[ngraham]

Most of these quirks aren’t actually design issues but rather technical ones. For example the scrollable control thing is tracked by https://bugs.kde.org/show_bug.cgi?id=399324.

Nobody has figured out how to make that happen yet.

Why don’t we take the easy step and just disable switch-on-hover? Because it’s actually an important interaction method used by many people; probably tens of thousands, maybe millions.

You wrote:

I doubt anyone intentionally changes dropdown values by scrolling - and if they do they shouldn’t.

That’s not the kind of thinking you can engage in when you’re considering the entire package and the whole userbase. If we just remove things that are blocking our ability to implement stuff we do want to change, eventually we’ll end up with almost nothing, annoy our core user base, lose our differentiation from GNOME, and then die because GNOME does being GNOME better than we ever would.

Some might say “okay, then just add a setting for this” but that doesn’t help either because defaults matter. Most people never change most settings, so what we choose as the default value would be the most important thing. “On by default” and we haven’t actually fixed anything; “off by default” and we still annoy the people using this, just not quite as much as if there was no way to get it back. And in the process we clutter up some settings UI somewhere and make the UX feel more “overwhelming.”

[vkhatab]

@ngraham here’s the linked issue

What we want here is that scrolling on controls still changes them

If this is the crux of the problem then it’s little wonder there’s no fix 7 years in. There is no fix because there’s no doing both. You either keep things the way they are with random values getting changed by scrolling or you block scrolling interaction where it’s not needed - Scrolling is generally used for zoom, volume and scrolling. If we can get rid of it in most other places without jeopardizing the stuff it’s actually needed for, then I think we should.

Do we really want scrolling on a combo boxes specifically to change their value? I certainly don’t and it’s not a “feature” on most other toolkits. I am not sure if anybody uses this, never mind millions. If anyone does use it that way - they shouldn’t: there’s a reliable way of changing the value of a combobox by keyboard or by clicking.

So assuming there is a way to turn this feature off specifically for combo boxes, the hurdle here would appear to be feature hoarding: we keep “features” just because they’re already there. As long as this is the approach, the source of broken behavior can never be resolved only papered over with additional “features” which in turn introduce new problems, and so on - it never ends.

[ngraham]

@vkhatab

I am not sure if anybody uses this, never mind millions. If anyone does use it that way - they shouldn’t: there’s a reliable way of changing the value of a combobox by keyboard or by clicking.

We won’t get very far with an attitude of “my usage of the system is the only normal and acceptable one.”

Engineering is about trade-offs. If we can’t even acknowledge there is a trade-off, then we’ll end up talking past one another and wasting each other’s time.

[vkhatab]

It’s not just my opinion if virtually every other toolkit besides QT agrees with me that it’s an anti-feature, and if in my usage all it demostrably does is cause accidental changes to settings. How do you even change the value reliably with a touchpad or freewheel scrolling if you wanted to? You’re liable to overshoot or undershoot most of the time.

This is why it’s important to understand how and why other platforms do things the way they do. Imagine if the dropdowns in the VSCode settings page had this kind of behavior? It’s absurd. Don’t take my word for it, actually look at how other people do things, none of the UX issues with KDE are some kind of uncharted territory.

[vkhatab]

I will add that this quirk is part of a more general “precise mousing” problem that KDE encumbers its users with. The fact that you have to aim the mouse in order to scroll a page is just the worst symptom of this general disease. If you look at gnome, they actually studied this stuff so there’s no careful mousing required. Every mouse target is big, obvious and intuitive. “Power users” don’t care course because they take pride in knowing precisely where every little thing is and love to challenge their mousing skills, but for everyone it leads to annoyance.

[vkhatab]

What’s the verdict here @ngraham ? Seems like this issue is fixable if KDE just does what literally every other platform does. One could make a toggle to enable “change random settings by scrolling” behavior in breeze settings for backward compatibility. If nobody end up using it it, the setting can be removed.

[ngraham]

I find your rude and sarcastic tone exhausting, so I’m conserving my energy by not engaging.

If you can find a way to express your thoughts politely, I’ll be happy to reconsider.

[vkhatab]

Who care about me or my tone lol? I’m nobody and my tone is normal for online forums. Consider the substance, it’s the end result that matters. Is my tone more important than your project?

[poljpocket]

Dear vkhatab,

I think, many on here appreciate feedback and are willing to discuss it, so long it is constructive.

What you are doing is spamming the forum, replying to yourself over and over and as of lately, you’re also insulting the very people you want to listen to you.

Why don’t you allocate this energy into something helpful?

If the design is so outdated and bad, come up with a solution instead! You don’t have to be a programmer to help. You can also simply suggest an improved design.

Also, please, stop comparing KDE to GNOME. If GNOME is so much better, you maybe should just use GNOME. That’s the beauty of using Linux: The choice is yours.

[ngraham]

@vkhatab

Who care about me or my tone lol? I’m nobody and my tone is normal for online forums. Consider the substance, it’s the end result that matters. Is my tone more important than your project?

It’s time to level up if you want to be taken seriously rather than arguing about tone.

Humans aren’t robots; how you communicate is usually more important than the actual content, when it comes to people being willing to listen to and consider that content.

If you’re willing to learn and grow and use a constructive tone, you’ll get better reactions and more consideration of your ideas.

If not, I suspect it’s only a matter of time before one of the moderators takes action.

The choice is yours.

[vkhatab]

I’ve explicitly proposed solutions - its stuff that everyone else already figured decades ago. All I get in return is denial, stonewalling and straightforward, repeated personal insults - while simultaneously whining about “tone” - because any direct, constructive criticism is seen an affront. You write “Dear so and so” here while another thread you express agreement with that “BANk the troll smam!” moron whose account is less than a month old.

I’ll won’t go into the theory of mind that makes you guys behave this way but clearly any further engagement on my part is complete waste of time. I’m out.

[poljpocket]

Yes, and I stand by that.

Let me remind you: Your whole thread Why "KDE looks dated" ... pretty obvious #UXQuirks doesn’t contain even a glimpse of a solution but insults like this:

@vkhatab

There’s a reason why Android doesn’t use that color everywhere anymore. You want the impression that KDE is “dated” and “clunky” to persist? Keep using this a the dominant color.

Or your other thread Apps can't raise windows on Wayland, something we've take for granted in desktop computing since forever isn’t about KDE but Wayland and why you think it is a mistake. No solutions either.

@vkhatab

If this is wayland after nearly two decades of development, with x11 being depreciated everywhere, I honestly don’t know what to say. Like maybe Wayland should’ve remained a protocol for Linux automotive, or Linux mobile, or whatever else the perpetual “next big thing” that nobody uses is, since quite obviously it was never designed with basic desktop usage in mind. Pretty much everything you need specifically for the desktop (remote access, sound, decorations, window management etc. was grafted on later as an “extension”). It’s like building a car and designing the steering wheel as optional addin ten years later lol.

Next, What is the point of saying the same thing four times? #UXQuirks is just one big insult starting with the title followed by “I hate Kirigami”. No solutions.

@vkhatab

And this design is literally everywhere with the advent of Kirigami. Either you make a “modern” app with customized titlebars (yes you can do it with server decorations too - look at Mac OS) or you dispense with the fixed toolbar entirely like a old school app would if it had basically nothing of substance to put up there. This however is some sui generis third thing specific to KDE and it’s decidedly not good.

So, sue me but please also show me where you explicitly proposed a solution. To me, this just feels like you’re looking for attention and controversy. And that is - by definition - what a troll does.

[rando]

If I may pointlessly write a perspective into the void of the internet and add to a probably dead conversation: I ran into this issue with volume control in a Panel. Very concerning because I suffer from tinnitus and randomly–and very accidentally–jolted my volume from a comfortable 20/100 to a breezy ~80/100 instantly, without meaning to. My ears are still ringing and probably will be tomorrow too.

I think if anything this “scroll to control settings potential setting” should be considered at least for cases like this, where physical harm can arise from unexpected input methods. Without getting bogged into design philosophy and technical feasibility, I think KDE, out of any DE in the world, would be the one DE I’d expect a toggle-able setting for this, especially since again, volume control can be very dangerous when there are unknown/unexpected input methods, which can cause harm to people and their audio equipment, potentially.

[jahinzee]

Adding my two cents into this: the “scroll to cycle through drop down options” is a very convenient feature I find myself using a lot to quickly cycle through giant dropdowns. It’s also very well supported not just on Qt apps, but also on many GTK and Windows-native apps.

I do, however, recognise it may be unintuitive for some or can get in the way, say if you need to scroll through something and your mouse happens to be resting on a dropdown – in that respect a settings toggle for “Cycle dropdown menu options with mouse wheel” might be a nice idea.

[LizLee]

Some might say “okay, then just add a setting for this” but that doesn’t help either because defaults matter. Most people never change most settings, so what we choose as the default value would be the most important thing. “On by default” and we haven’t actually fixed anything; “off by default” and we still annoy the people using this, just not quite as much as if there was no way to get it back. And in the process we clutter up some settings UI somewhere and make the UX feel more “overwhelming.”

i don’t get why “on by default” would mean “no fix”:

“on by default” imposes “off as an option”. an option to turn value scrolling via wheel in comboboxes off would exactly mean the problem is solved (for those who want to and actually do hit the opt-out-checkbox).

[GraysonPeddie]

Over the years of using Linux (about 15 years), when using KDE, I have dealt with controls in KDE System Settings where I’ve had to move my mouse away from the controls in order to keep scrolling through the page of settings. Before I was a web accessibility analyst, I never thought to bring this up until the OP called this out to our attention. This behavior of controls stealing focus from scrolling the page to scrolling the values not only can become a nuisance for users who may not have any disability issues, but it actually affects people with various kinds of disabilities.’

These disabilities include:

• Users with visual disabilities: They may have difficulty precisely positioning the mouse cursor, and unexpected value changes can be disorienting

• Users with motor disabilities: Those with tremors or limited motor control might struggle to avoid accidentally hovering over interactive elements

• Users with cognitive disabilities: Unexpected changes can cause confusion and frustration, potentially leading to errors; this includes those with mental and memory disabilities

• General users: Even without disabilities, this behavior can be jarring and lead to unintended settings changes; this is true especially for those who came from other operating systems such as Windows and macOS

This reminded me of Web Content Accessibility Guidelines, or WCAG for short. Although WCAG primarily applies to the web, WCAG can increasingly apply to software as well. Here are the following WCAG 2.2 Success Criteria that this focus-stealing scrolling behavior can violate:

• 3.2.1 On Focus: This success criterion states: “When any component receives focus, it does not initiate a change of context.” When scrolling causes a dropdown, slider, or number input to receive focus and immediately change its value, this violates this criterion. The element is initiating a change (to its value) simply by receiving focus, which is not permitted according to WCAG.
• 3.2.2 On Input: This criterion states: “Changing the setting of any user interface component does not automatically cause a change of context unless the user has been advised of the behavior before using the component.” The scroll wheel behavior could be seen as an “input” that changes a setting without the user intending to interact with that specific element. This would violate this criterion unless the user had been explicitly warned about this behavior.

Now, I don’t know about WCAG 2.4.3 as the WCAG standards obviously applies to users who must rely on keyboard for navigation, but I would like to copy a response that I’ve had conversations with Kagi’s AI:

WCAG 2.4.3 Focus Order and Mouse Users

WCAG 2.4.3 primarily addresses keyboard navigation and tab order, but it does have implications for mouse users in the context of our scroll wheel discussion.

How 2.4.3 Relates to Mouse Users

While 2.4.3 is fundamentally about keyboard navigation, it becomes relevant to mouse users in this specific scenario:

1. Focus Consistency: When scroll wheel interactions cause elements to receive focus unexpectedly, it disrupts the logical focus order that should exist regardless of input method. Even mouse users can be affected by inconsistent focus behavior when they switch between mouse and keyboard.
2. Predictable Interaction Model: 2.4.3 helps ensure that focus behaves predictably across all interaction methods. If scrolling with a mouse wheel causes focus to jump to unexpected elements, this violates the principle of a consistent, logical focus order.
3. Mixed Input Methods: Many users switch between mouse and keyboard. If scroll wheel interactions disrupt the focus order, it creates problems when users subsequently try to use keyboard navigation.

The Primary Issue Is Still 3.2.1

For the specific scroll wheel issue you described, WCAG 3.2.1 (On Focus) is actually the more directly applicable criterion:

• 3.2.1 states: “When any component receives focus, it does not initiate a change of context.”
• The scroll wheel behavior violates this because elements are both receiving focus AND changing values when the user is simply trying to scroll the page.

Balancing Tab Order and Mouse Interactions

To address your question about not violating tab order while accommodating mouse users:

1. Separate Concerns: The tab order (2.4.3) should be maintained for keyboard users, while scroll wheel interactions should be designed to not disrupt this order.
2. Explicit Focus Requirement: A good approach is to only allow scroll wheel to affect form elements when they have explicit focus (not just hover), which preserves both the tab order and prevents unexpected changes.
3. Focus Indicators: Ensure clear visual focus indicators so users understand which element currently has focus, regardless of how they’re interacting with the interface.

The key is ensuring that focus behavior is consistent and predictable across all interaction methods, which aligns with the spirit of multiple WCAG criteria, not just 2.4.3.

The controls in the System Settings application and just about all other applications can be referred to as “form elements” even though native GTK/Qt applications are not web pages.

I hope I can be of help despite using AI to copy a response from my conversation in here.

Oh, I do want to end my post by saying that accessibility deals with someone who has disabilities such as myself and that usability is about user experience and/or user-friendliness. Accessibility is a subset of usability and in this case, the controls stealing the scroll wheel from the page is in fact an accessibility issue. Improved accessibility benefits everyone even for those without any disability issues of any kind.