Linked by Thom Holwerda on Thu 10th Dec 2009 19:52 UTC
Graphics, User Interfaces For as long as I can remember, I've been having issues with scrolling in Windows and its applications. When scrolling via dragging the scroll blob, it seemed as if Windows had the annoying habit of randomly resetting your scroll blob to its starting position, which irritated me to no end. It took me a while to figure out, but I finally know when this behaviour occurs - now I just need to know: why?!
Permalink for comment 399090
To read all comments associated with this story, please click here.
Member since:

One of the oldest X toolkits, the X Athena Widgets (Xaw), default to a third way, which is very comparable to what you (in opinion possibly correctly) call the right way. Imagine a vertical scroll bar with a blob (I'll use this terminology) in a size representing canvas size vs. document size. If you click the left button inside the scroll bar - no matter where, the concent moves up (meaning your focus goes down) nearly page-wise.

You're almost right. The scroll amount depends on the distance from the top of the scrollbar. For example, left-clicking on the scrollbar at the height of the first line (from the top) will scroll down by 1 line, while right-click scrolls up by 1 line. And so on until the bottom of the scroll bar, where you scroll a screenful at a time.

The scroll-cancelling behaviour is one of the many things that irritate me whenever I have to use a Windows box (which, happily, is very rarely). GTK can do this with the Esc key.

BTW, GTK does have secondary scroll buttons. My .gtkrc-2.0 has:

style "scrollbar" {
# GtkScrollbar::has_secondary_forward_stepper = 1
GtkScrollbar::has_secondary_backward_stepper = 1
class "GtkScrollbar" style "scrollbar"

This gives a single up button at the top and both up/down buttons at the bottom of the scrollbar. Uncomment the first line for an additional down button at the top.

Reply Parent Score: 1