GTK3: Changing the overlay/momentium scroll bar

[Norbert_X]

Today I have documented another GTK-oriented problem - it is difficult to select last line in the Synaptic Package Manager.

See screencast is below from Ubuntu MATE 18.04 LTS:

(here I can't select last package named zzuf to installation;
screen size is reduced to get GIF smaller, the problem persists with full 1366x768 resolution).

All current Ubuntu version are affected, so I have reported the bug 1830437. On GNOMEs Hell the scrollbars are thinner, so I have added mate-themes and ubuntu-mate-artwork as affected packages.

I wrote about this problem here because of the fact that Synaptic is listed in MATE Software Boutique.

[lah7]

For the overlay scrolling, you can turn that off by adding this to ~/.bash_aliases (local) and /etc/environment (system-wide and root):

export GTK_OVERLAY_SCROLLING=0

That is... until GTK4 where this environment variable is gone. It'll then be up to the developer to expose an option in their application, if they want.

Reference: GTK - ArchWiki

---

I also noticed the scrolling behaviour feels more clunky in GTK3:

GTK3 - default in Ubuntu MATE

This also shows a glimpse of when the scroll bar doesn't always scroll when dragging it - I vaguely remember hearing this mentioned in the community before. Anyhoo, that behaviour can be changed in the theme:

/usr/share/themes/Ambiant-MATE/gtk-3.0/settings.ini

[Settings]
gtk-primary-button-warps-slider = true

So it works like this:

Like it did in 16.04 GTK2 - root apps only (?)

Reference: GTK - ArchWiki

I'm a bit confused at the default. I think the "warp" is the defacto GTK way (which I actually prefer) but Ambiant-MATE's default turns warping off. Only in 16.04 did it "warp" for root apps.

Turning off the warp for a moment, I wonder if we can adjust the scrolling timings - they are actually much slower then before.

GTK2 16.04 (left) - GTK3 19.04 (right)

Both of these are scrolling a Pluma text file of 150 blank lines

---

If you change any of the GTK settings above, you'll need to re-apply the theme or log out/in for it to take effect.

[arQon]

"warp" not "wrap".

all it actually means is that it swaps M1 and M3 when interacting with scrollbars. The scrolling itself is randomly broken in the same way either way. (Though nowhere near as much as trying to scroll with mousewheel, which is STILL broken AF even now).

[arQon]

@lah7 - re your "when the scroll bar doesn't always scroll when dragging it" bug, it is indeed caused by an attempt at momentum scrolling.
The root of the bug is that a "long press" switches the thumb into touchscreen mode (for want of a better term) and basically just breaks scrolling, as you've noticed. (And I do mean breaks: it makes it impossible to actually scroll anything that requires mouse travel beyond the available screen space, for example, totally defeating the point of having a scrollbar in the first place!).

You can't disable it, but you can change the amount of time it takes to trigger to something more appropriate than the default value - like about 3 weeks...

$ cat ~/.config/gtk-3.0/settings.ini
[Settings]
gtk-long-press-time = 2000000000

(It's a signed int)

Note that this can be overridden by a theme. (Remember, "Our branding is more important than what users want"). None of the MATE themes do, but it's so utterly broken that TBH I'm considering it for mine. The problem is that since GNOME prioritises the ini files the way it does, that means becoming as bad as they are and taking the choice away from the user. I'd rather see MATE provide a default ini file with the fix in it, but that's not up to me.

Anyway, that's another regression hacked around. Only half a dozen still to go before 20.04!

Since you have mod privs, you might want to split that part of your post out, along with this one and the confusion about the "warp" setting.

[arQon]

This one is especially frustrating, because I think there may actually be a use case for it: getting more precise scrolling, which could potentially be nice in some scenarios. Looking at the original bug reports though, when someone suggested implementing that properly via a modifier the idea was NIH'd.