GNOME Bugzilla – Bug 721893
scrolling with wheel should scroll by the same amount as a gtkscrollbar would
Last modified: 2021-06-10 14:47:15 UTC
Like to have the scroll wheel setting configurable as a whole in gnome. There should be an adjustment in gnome-terminal or gnome in general to set the scroll wheel line increment configurable. The RHEL6 scroll wheel step has been changed to 3 lines but it is not configurable. Ultimately it would be nice to make this a configurable option.
Christian, Do you think we want this?
RHEL6? Wow, that is really old. I don't think we (upstream GNOME) are going to support it. Having said that, in recent gtk+ versions if you are scroll then the content moves quite quickly. You can alter this behaviour by keeping the scrollbar pressed for a while before dragging it. That will cause it to move much slowly.
Debarshi, This is about scrol wheel (of mouse) AFAICT.
We do have a scrolling tab in preferences, so we could possibly add an option there. I will talk to chpe once he is back from vacation.
(In reply to comment #4) > We do have a scrolling tab in preferences, so we could possibly add an option > there. I will talk to chpe once he is back from vacation. Did he? did you? :)
I don't think this should be configurable. g-t allows to display a scrollbar next to the terminal. That scrollbar will react to the scroll wheel events by changing its adjustment; using the scroll wheel over the terminal itself should be made to reproduce the exact same change, for consistency.
See also: bug 748012 -- Contains details about current scrolling behavior. I'm not sure whether the conclusion there is right. bug 746690 -- With super smooth scrolling, the scrollbar can be dragged and result in sub-cell precision. When scrolling over the terminal area, however, I think it's better to jump by integer number of cells if scrolling with old-fashioned mouse wheel; actually, the current smooth scrolling patch even snaps the viewport to whole cells. This contradicts the request of the original report and chpe's comment. Other Gnome apps I've tried now (gedit, Files) also scroll with different speed over the actual content vs. over the scrollbar. Jacob, if you think this is really an issue, you should raise it on Gtk+/Gnome level. Once changed there, vte might see how to conform that behavior (which will be harder in vte due to the subcell vs. entire cell scrolling issue). Until then, I'd say it's NOTABUG/INVALID in vte.
(In reply to Egmont Koblinger from comment #7) > Other Gnome apps I've tried now (gedit, Files) also scroll with different > speed over the actual content vs. over the scrollbar. This doesn't seem to be the case anymore with gedit and nautilus on Fedora 23. gnome-terminal, however, still scrolls inconsistently with different increments.
GtkScrolledWindow scrolls by delta * page_size ^ (2/3), while vte scrolls by delta * page_increment/10 .
There are some more differences between VteTerminal and the classes inside GTK+. (a) While VteTerminal handles GtkWidget::scroll-event, none of the GtkScrollable implementations inside GTK+ do so. (b) Instead, GtkWidget::scroll_event is handled by containers like GtkScrolledWindow or GtkRange widgets like GtkScrollbar. GTK+ ensures that they use similar parameters for scrolling. My understanding is that (a) is necessary because of the mouse_tracking_mode code for mouse-aware terminal applications. To make the scrolling consistent, we can either override the scrollbar's scroll-event behaviour to match VteTerminal, or make VteTerminal match the scrollbar. The former seems more straightforward because the latter will require a solution to bug 746690 One option is to bake a "special" GtkScrollbar inside VteTerminal, like WebKitWebView. However, since VteTerminal already inherits from GtkWidget I don't know if we can do this without breaking ABI, because we would need to turn it into a container to pack things into it. Another option is to offer a VteScrollbar with the desired behaviour which applications can use for driving a VteTerminal. But, I haven't seen any other library do this, so I don't know if this is a good idea. Or, we can override the behaviour of the GtkScrollbar inside gnome-terminal, and keep it in sync with VteTerminal. Other vte applications would have to do the same.
I was chatting with Christian Hergert on IRC and here is another idea. How about we use tcgetpgrp to detect if there is a foreground process, and only handle GtkWidget::scroll-event in VteTerminal if there is one. Then applications can put VteTerminal inside a GtkScrolledWindow (bug 733210) to deal with scrolling like most applications do. However, I don't know whether that has a bearing on bug 746690
- I think this is being discussed in the wrong bug. - I cast a firm "NO" vote for the emultion or scrolling behavior depending on the process hierarchy etc. running inside (see also bug 764088), as opposed to solely the characters that have been emitted into the terminal.
(In reply to Egmont Koblinger from comment #12) > - I think this is being discussed in the wrong bug. Why do you think so? This is about scrolling the same amount regardless of where we use the mouse's scroll wheel. > - I cast a firm "NO" vote for the emultion or scrolling behavior depending > on the process hierarchy etc. running inside (see also bug 764088), as > opposed to solely the characters that have been emitted into the terminal. I didn't understand the relation with bug 764088 Could you please explain a bit?
Sorry, that was just another (irrelevant) bug where I expressed that the terminal's behavior must not depend on certain factors, such as termios settigs (in that bug), process groups (in this bug) etc. The behavior should only depend on the escape sequences that the terminal emulator receives.
(In reply to Christian Persch from comment #6) > I don't think this should be configurable. (In reply to Christian Persch from comment #6) > I don't think this should be configurable. Would you consider a hidden setting in gnome-terminal to change the scroll speed for the mouse wheel? > g-t allows to display a scrollbar > next to the terminal. That scrollbar will react to the scroll wheel events > by changing its adjustment; using the scroll wheel over the terminal itself > should be made to reproduce the exact same change, for consistency. Making VteTerminal and the scrollbar consistent is orthogonal to the original request. There are various options for that (see comment 10 and comment 11) depending on whether we continue to use a standalone GtkScrollbar or move to using a GtkScrolledWindow (bug 733210).
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/vte/-/issues/2048.