Created attachment 364139 [details] [review]
Patch to add gtk-overlay-scrollbar setting

Let's tag the right version. This was only dropped in GTK+ 4. Of course, it will remain in GTK+ 3.

That said, the comment in the commit removing the env var was:

>    This was never meant to be an official api, but rather
>    a transition help. Time to drop it for GTK+ 4.

so a setting seems unlikely.

(Seems the default assignee for GtkScrolledWindow and GtkStatusIcon bugs is wrong. Changing the assignee to be the GTK+ default assignee rather than the GLib one.)

[offtopic]
(In reply to Philip Withnall from comment #3)
> (Seems the default assignee is wrong.
Feel free to file a ticket about that against the Bugzilla product

Matthias, can you let me know why this bug has been closed?

Without an explanation I don't know if there is any way of getting a change upstream that will allow this behaviour to disabled.  There are other major UI issues that I'd like to get fixed too, but if there is an unwillingness to accept this kind of change then there is no point putting extra effort in to make the patch suitable for upstream.

In this case the code for proper scrollbars is still present and can be selected by applications so I assume it will continue to be maintained.  Allowing it to also be selected by the user doesn't make this significantly more complex.  The previous environment variable based method of disabling this didn't seem good, and I can understand wanting to remove that.

(In reply to Andrew Oakley from comment #5)

> Without an explanation I don't know if there is any way of getting a change
> upstream that will allow this behaviour to disabled.

The explanation is in comment #2.

Programmatic access is still available in GTK+ 4, and I'm not aware of plans to remove the API.

What we will not add is a user-accessible toggle, or an environment variable. This is an application developer decision, not a toolkit setting. If the application developer wants to provide an application-specific setting and wire it to the GtkScrolledWindow API, it's entirely in their capacity to do so.

> There are other major
> UI issues that I'd like to get fixed too, but if there is an unwillingness
> to accept this kind of change then there is no point putting extra effort in
> to make the patch suitable for upstream.

Unless all those "major UI issues" involve the ability to disable overlay scrollbars, you should file bugs for those.

The old style always visible scroll bars are much easier to use with a wacom tablet. It will be a loss to have them go.

Who ever said they were going to "go"? The API to make an application use them is still there. Programs used frequently on tablets or such can take feature requests to have their own options to use non-overlay scrollbars.

(In reply to Daniel Boles from comment #8)
> Who ever said they were going to "go"? The API to make an application use
> them is still there. Programs used frequently on tablets or such can take
> feature requests to have their own options to use non-overlay scrollbars.

So I just need to file a feature request against every gtk application that I use? And when I install GNOME I'll need to go into each application and enable it.

I just wanted to correct the record that the ability to use overlay scrollbars is still there, albeit not accessible how people prefer(i.e. to rephrase Comment 6). Note that I personally would also like a setting for this, but that means nothing.

(In reply to Emmanuele Bassi (:ebassi) from comment #6)
> (In reply to Andrew Oakley from comment #5)
> 
> > Without an explanation I don't know if there is any way of getting a change
> > upstream that will allow this behaviour to disabled.
> 
> The explanation is in comment #2.
> 
> Programmatic access is still available in GTK+ 4, and I'm not aware of plans
> to remove the API.
> 
> What we will not add is a user-accessible toggle, or an environment
> variable. This is an application developer decision, not a toolkit setting.
> If the application developer wants to provide an application-specific
> setting and wire it to the GtkScrolledWindow API, it's entirely in their
> capacity to do so.
> 
> > There are other major
> > UI issues that I'd like to get fixed too, but if there is an unwillingness
> > to accept this kind of change then there is no point putting extra effort in
> > to make the patch suitable for upstream.
> 
> Unless all those "major UI issues" involve the ability to disable overlay
> scrollbars, you should file bugs for those.

I don't like overlay scrollbars. They aren't easy to use whether with mouse or with wacom tablet. It's not easy to get the mouse or stylus over the spot required to make the scrollbar reappear, and when it does reappear other stuff in the UI has to move to make room for it - visually *very* distracting.

At least in GTK+3 the very awful and user-unfriendly overlay scrollbars can be disabled by the user. But this bug report indicates that in GTK+4 the user's only recourse will be to beg and plead with the developers of each and every GTK application to please provide a way to disable overlay scrollbars. This is not a good thing! Please reconsider and reopen this bug report. 

Overlay scrollbars are a major inconvenience, a hindrance to smooth workflows. I see from perusing the internet that I'm not the only person to feel this way. 

Using or not using overlay scrollbars should be a user option, not something forced on users by developers.

I depend on this feature. Removing options like this makes it harder for with visual impairment or other similar disabilities. I don't like it but it looks like I'm going to need to find Qt alternatives to all the GTK software I currently use.