GNOME Bugzilla – Bug 89259
Make scroll wheel step dimensionally correct
Last modified: 2016-09-23 11:34:23 UTC
Currently the mousewheel in Gtk Textviews (I'm mainly talking about gedit, just assuming that it's controled by the Gtk widget) scrolls about half a page. At this speed it is very hard to keep track of where I am and it usually happens to me that I completely loose track whenever I use the scrollwheel. Other applications always scroll about three lines at once (like Moleskine or Mozilla), that's very easy to follow. The current behaviour might be advantegous when scrolling through large files, but this advantage becomes dubious when I constantly miss what I'm looking for because it's going by so fast. I would much rather use the scrollbar when looking for something in a large file (because it scrolls smooth and/or fast) but use the scrollwheel for fine adjustment.
I agree. It is very difficult to track the contents when we scroll half a page. We should probably instead scroll 3 * step_increment instead of page_size / 2. Also, widgets generally set step_increment to 10% of the widget's allocation unless they have the concept "line". I think this value should instead be something like MIN (33, 10%) so that the result of both step and wheel operations become more predictable (if wheel events become 3 * step_increment). For the wheel events, this is easy to fix for most widgets - just change page_size/2 to step_increment * 3 in gtkscrolledwindow.c and gtkrange.c. The step_increments must be fixed on a widget-by-widget basis.
Where does 33 come from? And if we are going to pick a magical number of pixels, shouldn't we just use that, rather than including the 10% in there as well?
33 comes from the usual "seems right to me". I can comfortably track about 100-140 pixels per wheel event on a 1600x1200 21" monitor and 33-40 is not an unreasonable amount for a step. The exact numbers are negotiable, of course. We shouldn't use the magic constant for all cases, because when the allocation gets smaller than 33, this would make stepping scroll more than was visible on screen, which would be confusing. I think in this case, 10% is not unreasonable and so, to get a continous function, I suggest MIN (33, 10%).
I'll add that the numbers could be different from widget to widget The text widget might require a smaller step_increment than the tree widget because tracking running text is more difficult than tracking a vertical list.
I think this is going to require some demo patches for people to play around with and see what works best.
ping. This seems like a problem that should be fixed for Gnome 2.4. The scroll wheel is essentially useless as it stands for the gtk2 versions of apps like evolution and gedit. The 3 lines of scrolling seems to be the accepted norm in almost every other app that I can think of, but this might also make sense as a mouse preference in gnome control center, along with the pointer acceleration, but that's certainly debatable. How hard is this to fix?
This won't be changed for GNOME-2.4, since GNOME-2.4 will be based on GTK+-2.2, and this isn't the sort of thing we want to change in maintenance releases. My comment above stands for what is needed here next ... some demo patches for people to play around with.
Created attachment 20086 [details] [review] Patch to make the wheel scroll page_size^(2/3)
I just attached a patch to make the wheel scroll page_size^(2/3). That formula works very well for me, but see http://mail.gnome.org/archives/gtk-devel-list/2003-June/msg00116.html and the follow-up for discussion about the scroll-step. (Something like if (GTK_IS_SCROLLBAR (range)) use pow(page_size, 2/3) else use linear_function(page_size); may be possible, or even have the wheel step virtualized for GtkRanges)
Can't we just use MIN(page_size, 3 * lineheight) like KDE (and Mozilla) seem to do? That makes a lot of sense to me. It's consistent and the dependence on font size makes it somewhat resolution independant. The maximum of it's own size makes sure that you never scroll more than one page on very small widgets. It's also simple, tried and tested. Unfortunately I couldn't figure out how to calculate a proper lineheight (fontsize + something?), so I'm currently testing it with fixed values, but I like it a lot so far.
Adding the PATCH keyword.
Created attachment 24631 [details] [review] New patch that only uses the power function for scrollbars
Retitling and leaving bug open to track the isssue of whether we should normalize based on font size, ie. use something along the lines of font_size * pow (page_size / font_size, k); Sun Feb 29 19:04:33 2004 Soeren Sandmann <sandmann@daimi.au.dk> * gtk/gtkrange.c (_gtk_range_get_wheel_delta): New internal function returning a good step value for the mouse wheel. For scrollbars, base the step on page_size^(2/3), for other ranges, use 2 * step_increment. * gtk/gtkrange.c (gtk_range_scroll_event): Use it here ... * gtk/gtkscrolledwindow.c (gtk_scrolled_window_scroll_event): ... and here. * gtk/gtkmenu.c (gtk_menu_leave_notify): Fix a warning.
How about making it configurable? Obviously there is no one universal or magic number!
Isn't it time to close this bug? AFAICT the meat of the patches have been applied and the issue solved?
I was just reading git logs for this, and I've not heard anybody complain about scroll wheel performance forever, so I consider this closed. Also, the patches here are committed since 2004.
Please make it page_size/4! page_size^(2/3) is unusable on high-resolution screens.
So maybe this should be looked at again?