Bug 1495520

Also somewhat relevant: https://git.gnome.org/browse/vte/commit/?id=a9b0b4c and https://bugzilla.gnome.org/show_bug.cgi?id=786778. For the time being, Ctrl+Shift+Up/Down can be used to snap the view to aligned lines (and later, scroll by a line).

As I understand, you're mostly worried about the huge difference between scrolling by a complete page (as Shift+PageUp/PageDown also does) and a partial line; and even if it scrolled by 1 entire line you would have filed this bug, correct? So scrolling by partial lines is not your primary concern if I understand you correctly.

Exactly. Customer(and me too) prefers old behaviour when right click makes full page scrolled. So - yes - it's not a matter of partial or full line scroll but rather full page.

I see, thanks. Unfortunately I cannot comment on the technical side of that story.

One possibility is for you to revert that change, if it indeed fixes (or rather: works around) the problem.

I've noticed however that Gedit and Files (nautilus) also scrolls by a tiny amount, probably many other apps. So it looks to me the core problem is somewhere in Gtk+'s scrollbar (GtkScrolledWindow) and ideally should be fixed there.

Maybe there is a way to change the behavior from a config file, I don't know.

I personally completely agree with you and your curstomer that the old behavior is much more useful.

It's also reproducible in the vte test app, so this has nothing to do with the change mentioned in gnome-terminal, or with GtkScrolledWindow. Since it's also reproducible in other apps (tried gedit), it's probably a gtk+ bug, likely introduced in porting it to gestures.

Please upstream this on bugzilla.gnome.org, for gtk+.

(In reply to Dmitry Zhukovski from comment #0)
> It looks like this change was implemented in 3.21[1]:
> -------------
>     window: Support animated and touch scrolling
>     
>     Add back code to conditionally compile TerminalScreenContainer
>     to use a GtkScrolledWindow instead of creating our own GtkScrollbar.
>     When used, this gives us animated and touch scrolling for free.
>     We can mimic the existing behaviour by creating a GtkScrolledWindow
>     that never scrolls horizontally, but always vertically. We can
>     use the new EXTERNAL policy to hide the vertical scrollbar widget
>     depending on the setting.
>     
>     However, GtkScrolledWindow doesn't work with
>     GTK_SIZE_REQUEST_CONSTANT_SIZE children, so this code will only
>     exist for development purposes until gtk+ fixes this.
>     
>     Also install custom CSS to hide GtkScrolledWindow over/underscroll
>     animations.
>     
>     Also reverts commit 41eb2ec73653adc5fd36fa73cebdc8a6169f8516
>     
>     https://bugzilla.gnome.org/show_bug.cgi?id=733210

For the record, no that's not it. That code is under #ifdef USE_SCROLLED_WINDOW guards and we don't enable those paths.

Turns out that this behaviour is intentional. In fact the speed at which it smooth scrolls varies depending on the distance of the pointer from the scrollbar's trough. If you move the pointer away, while keeping the secondary mouse button pressed, it will speed. Bring it back and it will slow down.

It is the variable speed variant of smooth scrolling.

The behaviour that you are looking for, can be achieved by shift + primary-click. You can swap the behaviour of primary-click and shift + primary-click using the gtk-primary-button-warps-slider setting.

I know that paging effect can be archived by Shift - Primary button. But customer is asking where is gone 7.3's right button paging effect.

(In reply to Dmitry Zhukovski from comment #10)
> I know that paging effect can be archived by Shift - Primary button. But
> customer is asking where is gone 7.3's right button paging effect.

As I said in comment 9, it was taken up to implement yet another variant of scrolling.

Debarshi - you can close this BZ. Customer has agreed with close-to-okey Shift-Primary button solution.

(In reply to Dmitry Zhukovski from comment #12)
> Debarshi - you can close this BZ. Customer has agreed with close-to-okey
> Shift-Primary button solution.

Ok. Thanks for the feedback!

Development Management has reviewed and declined this request. You may appeal this decision by reopening this request.