Bug 416003

I'm not really sure this should be configurable; it's the kind of thing people complain about when they say that KDE software feels "overwhelming" and "overcomplicated."

As I suspected when I saw the bug report title, the reason why you want to configure the size is because you think the current scrollbar width is too narrow. If this is true, then you're not alone, and we get many complaints about this. As such, I'm going to mark this bug as a duplicate of the issue that tracks widening the scrollbars.

Personally I think that the scrollbars should be wider (AKA normal) when in desktop mode, and only get narrow when using the system in touch mode, where typically people don't interact with the scrollbars directly and instead scroll by flicking on the content view itself.

*** This bug has been marked as a duplicate of bug 396747 ***

This is 100% an accessibility feature, as I know of at least one user with hand mobility impairments that relies on scrollbars with an increased size because using the mouse scroll wheel is difficult.

They either have to use a desktop environment that is based on GTK, or use Qt themes that allow you to adjust the scrollbar width, as Breeze is off the table entirely.

This was marked as resolved in Plasma 5.18.0, but I'm using 5.18.5 and cannot adjust the scrollbar width via Plasma. As a result, the impaired user cannot use Plasma Desktop with the Breeze theme.

If using the scrollbars at their current size is difficult, it's highly likely that everything else in the system is similarly difficult, and the proper solution is use global scaling to make everything bigger. Making just scrollbars bigger while everything else remains the same size does not make sense to me.

(In reply to Nate Graham from comment #3)
> If using the scrollbars at their current size is difficult, it's highly
> likely that everything else in the system is similarly difficult, and the
> proper solution is use global scaling to make everything bigger. Making just
> scrollbars bigger while everything else remains the same size does not make
> sense to me.

I'm familiar with how this impaired user uses their computer, and this is simply not the case. Their impairment makes it difficult to use the scroll wheel, and they depend on clicking on and grabbing a larger scrollbar to navigate long pages. To make this easier, they rely being able to increase their scrollbar size.

What I'm saying is that if clicking on small things is hard, they should make *everything* larger, not just the scrollbars. It does not make sense to me that a person would have difficulty clicking on small scrollbars but would have no trouble clicking on small window close buttons, sliders, list items, etc. Those are of a similar size and should therefore be similarly difficult to click on with their default sizes. So they should be made larger as well. Therefore if clicking on small things is hard, the solution is to make everything larger--not just one of those small things.

(In reply to Nate Graham from comment #5)
> What I'm saying is that if clicking on small things is hard, they should
> make *everything* larger, not just the scrollbars. It does not make sense to
> me that a person would have difficulty clicking on small scrollbars but
> would have no trouble clicking on small window close buttons, sliders, list
> items, etc. Those are of a similar size and should therefore be similarly
> difficult to click on with their default sizes. So they should be made
> larger as well. Therefore if clicking on small things is hard, the solution
> is to make everything larger--not just one of those small things.

I understand that that's what makes sense to you, but the impaired user's use case goes against those assumptions.

For the impaired user, they have the need to increase the scrollbar size, but no need to increase the rest of the UI. Again, this is because they have difficulty using the mouse scroll wheel.

The scrollbar on Breeze is very thin, thinner than the scrollbar on older versions of Windows or macOS. If there is no way to increase the size of the scrollbar like it can be using other Qt themes or GTK, they will necessarily need to use something other than Breeze.

> For the impaired user, they have the need to increase the scrollbar size
> [because] the scrollbar on Breeze is very thin
Can you explain why the impaired user does not have trouble with sliders and list items which are similarly thin?

Qt has a 'global strut' feature, and styles should respect the values set there. Unfortunately, newer Qt versions removed the qtconfig tool, and setting this value requires support from the QPA.

https://kdepepo.wordpress.com/2009/03/12/global-strut-feature/

(In reply to Nate Graham from comment #7)
> > For the impaired user, they have the need to increase the scrollbar size
> > [because] the scrollbar on Breeze is very thin
> Can you explain why the impaired user does not have trouble with sliders and
> list items which are similarly thin?

The user spends 99% of their time on the internet when they use their computer, and the majority of websites require scrolling. They find themselves needing to grab the scrollbar with the cursor and move it up and down to navigate pages, and need to do that each time they click and load a new page. They specifically increase the scrollbar width to aid in doing this, because it is frustrating and difficult to constantly need to use something as thin as Breeze's scrollbar just to use the internet like everybody else can.

The user does not need to use sliders at all when browsing the internet. List items are not only a few pixels wide.

This is something that is configurable in GTK and other Qt themes. It's unfortunate that Breeze isn't an option for this user, given that it is the default theme for so many Plasma based distributions.

Which browser do they use, and do those browsers actually respect the QStyle? Confirm it by changing the widget style via 'kcmshell5 style'.

I am not handicapped, and I have trouble with the tiny scrollbars in my HiDPI configuration.  I think that debating whether someone needs the ability to configure the option is substantially off-target, especially if it's an accessibility issue for THEM.  If the problem on the developer's end is an "interface complexity" issue, why not provide a config file that can be edited to adjust the scroll bar width?  This shouldn't affect perceived complexity for the average user at all.

Having said that I'll attempt to respond to Nate's most recent (rhetorical?) question:  The scroll bar in my configuration is substantially more narrow than most other controls which are typically square and much larger.  My scrollbars appear to be 10 pixels wide, which at 160dpi is less than a 1/16th of an inch.   The scroll bars in Firefox in the default configuration were even smaller, probably 1/24th of an inch.  I would like for the scroll bars to be at least twice as large, and possibly more like 3 times as large as they are currently, which would make them comparable in size to most other controls in my configuration.

There's an enormous number of questions on the Internet about this, and three-quarters of them do not work or are horribly out-of-date.  For example, Christoph Feck's link in this ticket to global strut is from more than 12 years ago, recommending qtconfig that hasn't worked since Qt5, which came out 8.5 years ago.   There's also a lot of talk about editing files in /usr/share/themes but this doesn't seem to really work either.  My impression is that file is for controlling Breeze compatibility in GTK apps, not native KDE & Breeze, although I'll admit that maybe I just don't understand how that works or how to test it (nobody else really seems to understand either in my experience).

I think the real problem here is that without a GUI settings control or at least reliable advice on what to do nobody can figure out how to fix this problem when they have it.  If there's a system configuration change that will alter the scrollbar width system side in Breeze, can someone please mention it here?  

For the original poster, who seemed mostly interested in fixing the problem in their web browser...   In Firefox 89.0.1, entering "about:config" into the address bar, and then changing the value of widget.non-native-theme.scrollbar.size produced the desired result in Firefox in my configuration.  Now if only I could get the same effect in all other Breeze/KDE applications...

The tiny-scrollbars-everywhere trend continues to inflict pain on a non-miniscule percentage of computer users. Does it need years of debating to give people some choice here? a very simple settings widget would empower thousands to more comfortably use KDE..
Clearly the problem is not resolved yet (a setting was put in, but then removed again).

Please don't re-open closed bug reports.

I came across this page while looking for a solution to this problem as well, and I can't believe what I had to read here. Some one asked about the possibility for setting a certain value dependent on a user's wish and needs, and then a discussion about the user's abilities starts. 

If that user had a need for a special type of steering wheel in a car, would you also ask why this is so?

I totally agree to Cory's and Marcel's statements. Users, handicapped or not, want this feature and need they need this feature. Providing small and next to no scrollbars may make sense on touchscreens where you can swipe, but on a modern hdpi screen they are a pain!

Unfortunately, even reverting to the "old" Oxygen style does not provide the needed option any more. So, unless the developers of KDE will reconsider their decision about removing this feature, the should not be wondering when more and more Linux users will be starting other desktops where this option is still available. That would also be my advice to AlexDeLorenzo's friend, if they did not find a better solution yet.

I think the people here talking about a overly thin scrollbars in their *web browser*--particularly if that web browser is Firefox--may be suffering from a misconception. We are able to style Firefox's scrollbar via our Breeze-GTK theme, but we are unable to make it any wider. So the best we can do is to make the overly-thin 10px wide scrollbar in Firefox be a Breeze-styled overly thin 10px wide scrollbar. The scrollbar being ridiculously thin is a Firefox issue and unfortunately we can't correct it in our styling.

In Qt apps, we don't have this problem because we have full control over the scrollbar's visuals and sizing. So allow me to point out that the scrollbars in Breeze-styled Qt apps are not actually narrow at all; the clickable area itself is 44 pixels wide--over 4 times the thickness of Firefox's somewhat absurd scrollbar--even if the bar itself is *visually* somewhat narrow. This interactive click area is very generous--by design--and much more so than the scrollbars you get in GTK apps or even on macOS these days.

And let me also repeat that if you are using a high-DPI screen and find the Breeze scrollbars in Qt apps too small, this is because you haven't set the display scaling properly and so everything else will be too small as well; once you set the scale properly everything--including scrollbars--will appear at the correct intended size. The use case of wanting only scrollbars to be huge but nothing else isn't something we plan to support, as it breaks the intended size relationships between objects.

(In reply to Nate Graham from comment #1)
> I'm not really sure this should be configurable; it's the kind of thing
> people complain about when they say that KDE software feels "overwhelming"
> and "overcomplicated."
> 
> As I suspected when I saw the bug report title, the reason why you want to
> configure the size is because you think the current scrollbar width is too
> narrow. If this is true, then you're not alone, and we get many complaints
> about this. As such, I'm going to mark this bug as a duplicate of the issue
> that tracks widening the scrollbars.
> 
> Personally I think that the scrollbars should be wider (AKA normal) when in
> desktop mode, and only get narrow when using the system in touch mode, where
> typically people don't interact with the scrollbars directly and instead
> scroll by flicking on the content view itself.
> 
> *** This bug has been marked as a duplicate of bug 396747 ***

It should be. Because when you use touchscreen you can't scroll window contents. If you try to scroll text field using touchscreen, the text will be selected. If you try to scroll system settings window - it will no react.

Actually we also need a settings to increase option box radius and checkbox mark size.
I have touchscreen on Dell laptop from 2015 guys. Very painful to realize that no one cares about UX.

Also panels and sensors in Plasma 5 are buggy and nobody really test it by hands. I don't really believe that someone will fix bugs when new Plasma 6 is coming. I also know that UI stuff never has critical severity. So I am just telling you how painful is to be a KDE Plasma touchscreen user.

Please submit real bug reports for real issues, not requests for workarounds for real issues.