GNOME Bugzilla – Bug 692037
Improve scrolling in long views
Last modified: 2018-04-15 00:29:00 UTC
In this comment: https://bugzilla.gnome.org/show_bug.cgi?id=563688#c11 the assertion is made that both sliders and scrollbars should jump to absolute position. I can't find a link to the rationale for that, and I think it's a mistake for scrollbars to behave that way. We can't prevent arbitrarily large scroll fields - think web pages, if nothing else - which means a single pixel's worth of granularity can be too coarse to position accurately. On touchscreens you rarely have even one pixel's worth of accuracy, much less the ability to right-click to get the old paging behaviour.
+1 (couldn't find a vote feature)
+1 here too. It makes large mailboxes really difficult to navigate.
In order to make a constructive proposal: - move the new functionality (jump to absolute position) to the right mouse button, which was previously unused, and which seems a good place to add new functionality - restore the old default functionality of the left mouse button
I advocated for this change for a few reasons. * Applications that require use of paging because manipulating the scrollbar handle is impossible due to insufficient precision in a huge list should find a better design. * While it is customary for scollbars to page on trough clicks it is illogical and unmotivated. There is no affordance for relative moves when clicking inside an absolute position bar. * Trough paging is inconsistent with the behavior of other types of range sliders. Those logically follow the absolute position affordance. * The paging behavior on click and hold was wrong. It would not page up to the pointer position and stop. It would page past the pointer and continue to the end. That makes no sense. * I hoped to do something smarter with the fine tune scroll (what is now shift+drag) by default and that would mean we would need a better way to do absolute (very large) position changes. The above are still true. However, I am not sure the new behavior is actually better and since it is different it is causing people some discomfort. I think any additional change must try to address the root problem: people trained to avoid or are forced to fall back to using the scroll handle in long views. Perhaps we can try: 1. Making scrollbar differ from scale widgets by using relative positioning (paging) on left click and absolute on right click 2. Modifying the paging behavior to be truly relative (ie. stop paging when the handle reaches the pointer click position) 3. Using fine tune scrolling by default for low velocity drags. This will help with the problem where the first pixel of handle move results in a large and disruptive move in the view. 4. Retaining existing shift+drag behavior
*** Bug 696046 has been marked as a duplicate of this bug. ***
We're moving to gitlab! As part of this move, we are moving bugs to NEEDINFO if they haven't seen activity in more than a year. If this issue is still important to you and still relevant with GTK+ 3.22 or master, please reopen it and we will migrate it to gitlab.
As announced a while ago, we are migrating to gitlab, and bugs that haven't seen activity in the last year or so will be not be migrated, but closed out in bugzilla. If this bug is still relevant to you, you can open a new issue describing the symptoms and how to reproduce it with gtk 3.22.x or master in gitlab: https://gitlab.gnome.org/GNOME/gtk/issues/new