After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 793824 - Remove tab scrolling workaround
Remove tab scrolling workaround
Status: RESOLVED FIXED
Product: gnome-terminal
Classification: Core
Component: general
3.27.x
Other Linux
: Normal enhancement
: gnome-3-30
Assigned To: GNOME Terminal Maintainers
GNOME Terminal Maintainers
Depends on:
Blocks:
 
 
Reported: 2018-02-25 23:29 UTC by Egmont Koblinger
Modified: 2018-06-12 14:06 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Egmont Koblinger 2018-02-25 23:29:40 UTC
"Tab scrolling was removed from GtkNotebook in gtk 3, so reimplement it here" – says gnome-terminal twice: for the regular terminal tabs, and for the profile prefs.

There's at least two problems with this feature:

1. Movement along both axes are handled. Vertical moment is converted to horizontal so that the traditional mouse wheel is usable. Handling horizontal is desired for the more intuitive behavior with touchpads. This results in "/"-diagonal touchpad movement crazily jumping back and forth between tabs. Even if the finger movement is intended to be horizontal or vertical, small deviations might cause occasional steps in the opposite direction. (This is actually a pretty common usability bug present on plenty of webpages.)

2. With "natural scrolling", the behavior is the opposite of what's expected. The mapping of up->right and down->left is at least unusual, but swapping left and right is just bad. I'm not sure but at first glimpse it doesn't seem to me that scrolling events have a "natural" flag, so we'd need to keep an eye on the GNOME-wide setting in order to swap it back.

I _guess_ that these might have been some of the reasons why GTK+ decided not to handle physical scroll events where their interpretation would be something else than actually scrolling some contents.

I vote for just accepting GTK+'s decision here, and not workaround in a way that has these two problems.

(Plus, it doesn't work on the merged prefs's sidebar, and I really don't feel like adding this workaround there too, even despite that it wouldn't suffer from the diagonal issue.)
Comment 1 Egmont Koblinger 2018-02-26 00:16:07 UTC
(In reply to Egmont Koblinger from comment #0)

> I _guess_ that these might have been some of the reasons why GTK+ decided
> not to handle physical scroll events where their interpretation would be
> something else than actually scrolling some contents.

(Well, this is not quite true, e.g. scrolling events are handled in numeric entry boxes (such as initial terminal size). And "natural scrolling" also swaps the direction here, making it pretty unintuitive.)
Comment 2 Christian Persch 2018-03-03 18:56:06 UTC
Ok with me.
Comment 3 Egmont Koblinger 2018-03-03 18:59:18 UTC
IMHO let's not do this last minute during UI freeze :) Targeted for 3-29.
Comment 4 Andrey Gursky 2018-06-12 14:06:02 UTC
Regarding [1]. There are users having no problems with tab scrolling but having them without it. This is the essential feature for usability with more than a few tabs.

[1] "notebook: Remove tab scrolling workaround" https://gitlab.gnome.org/GNOME/gnome-terminal/commit/b1b26a1d3f333171c3a2a0c14d93b14b38054e6d