You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I made a list-box% with a bunch of items in it, and then I scrolled it with my mouse's scroll wheel. (You can observe this in DrRacket, too, e.g., Preferences -> Editing -> Indenting -> "Lambda-like Keywords".) This is on Linux/X11.
Scrolling down one wheel notch at a time, it sometimes scrolls at 3 lines per notch, and sometimes 2. Scrolling up in the same list is significantly faster: after scrolling 10 notches down, for example, it takes only 6 notches up to return to the top.
In contrast, a native GTK3 program always scrolls by a consistent amount in both directions. It's about 3 rows per notch, but it's not an exact number of text rows. (Racket GUI list-boxes seem to require the top line of visible text to align with the top of the viewport, while GTK3 scroll areas can scroll to any pixel position.)
Racket GUI lists also use "smooth scrolling", while other GTK3 programs (at least on my computer) do not. This is weird but would not necessarily be a problem, as long as the scrolling speed were comparable. For example, when I move my finger from the lowest to highest mouse wheel positions, I can move it through 10 notches. If I spin it quickly, it goes about twice as many notches, due to momentum. Normal GTK3 scrolling seems to measure the number of notches the wheel spins, while Racket GUI scrolling seems to measure the time it spends in rotation -- and so it scrolls less far when spun quickly, even though it spins twice as many notches. To scroll down by 100 lines in the GTK3 file picker, it takes 2 quick spins of my mouse wheel. In a similarly sized Racket GUI list, to scroll down by 100 lines, it takes 12 spins of my mouse wheel.
While I think that GUI libraries should generally follow the platform conventions, I don't think that either of the racket/gui scrolling modifications (smooth scrolling; snapping to full rows) is necessarily bad -- but they might be problematic if they're contributing to bigger issues (like making it 6 times slower).
Specifically: even more than mimicking the native scroll behavior exactly, I think the more fundamental principles of mouse wheel scrolling should be:
one scroll wheel notch should always scroll by the same amount (at any point in the list, and in either direction)
spinning the scroll wheel quickly should scroll the view based on the angle the wheel has spun, not the wall time it spent in motion
scrolling speed should be roughly the same in all applications
As for that last point, the programs I use the most these days are Emacs, Firefox, and a GTK terminal emulator, and they all clearly have their own unique scrolling implementations, but they're all fairly similar in speed, and much closer to each other than Racket GUI is to any of them.
The text was updated successfully, but these errors were encountered:
I made a
list-box%
with a bunch of items in it, and then I scrolled it with my mouse's scroll wheel. (You can observe this in DrRacket, too, e.g., Preferences -> Editing -> Indenting -> "Lambda-like Keywords".) This is on Linux/X11.Scrolling down one wheel notch at a time, it sometimes scrolls at 3 lines per notch, and sometimes 2. Scrolling up in the same list is significantly faster: after scrolling 10 notches down, for example, it takes only 6 notches up to return to the top.
In contrast, a native GTK3 program always scrolls by a consistent amount in both directions. It's about 3 rows per notch, but it's not an exact number of text rows. (Racket GUI list-boxes seem to require the top line of visible text to align with the top of the viewport, while GTK3 scroll areas can scroll to any pixel position.)
Racket GUI lists also use "smooth scrolling", while other GTK3 programs (at least on my computer) do not. This is weird but would not necessarily be a problem, as long as the scrolling speed were comparable. For example, when I move my finger from the lowest to highest mouse wheel positions, I can move it through 10 notches. If I spin it quickly, it goes about twice as many notches, due to momentum. Normal GTK3 scrolling seems to measure the number of notches the wheel spins, while Racket GUI scrolling seems to measure the time it spends in rotation -- and so it scrolls less far when spun quickly, even though it spins twice as many notches. To scroll down by 100 lines in the GTK3 file picker, it takes 2 quick spins of my mouse wheel. In a similarly sized Racket GUI list, to scroll down by 100 lines, it takes 12 spins of my mouse wheel.
While I think that GUI libraries should generally follow the platform conventions, I don't think that either of the racket/gui scrolling modifications (smooth scrolling; snapping to full rows) is necessarily bad -- but they might be problematic if they're contributing to bigger issues (like making it 6 times slower).
Specifically: even more than mimicking the native scroll behavior exactly, I think the more fundamental principles of mouse wheel scrolling should be:
As for that last point, the programs I use the most these days are Emacs, Firefox, and a GTK terminal emulator, and they all clearly have their own unique scrolling implementations, but they're all fairly similar in speed, and much closer to each other than Racket GUI is to any of them.
The text was updated successfully, but these errors were encountered: