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 399008
To read all comments associated with this story, please click here.
Spanish inquisition - expect it!
by Doc Pain on Fri 11th Dec 2009 05:05 UTC
Doc Pain
Member since:
2006-10-08

Thom, you wrote: "Clicking inside the scrollbar, but outside of the blob, can have two different outcomes, depending on system settings and operating system used: the right one, and the wrong one."

In fact, there are those two ways: the right one, the wrong one, and a differnt one. Three! Three ways! :-)

You missed the third one, but maybe you're not familiar with it, so let me explain:

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. If you click the right mouse button, the opposite happens. But when you click the middle mouse button (and we all can remember that PCs and especially "Windows" didn't utilize the concept of a three button mouse very much), the blob gets to the position you exactly clicked at. You can hold down the middle mouse button and scroll as slow or as fast as you like - the blob stays "connected". This is the behaviour that you expected for clicking inside the scroll bar, but outside of the blob in terms of the right way.

I know that "nearly page-wise" is an arbitrary amount of space (lines, pixels, whatever) again, and that's a downside as you mentioned it when describing what happens when you click inside the scroll bar, but outside of the blob in terms of the wrong way.

According to your question "Can anyone tell me if other systems have been affected by this bug as well?" referencing the "leave the window to reset" problem:

When I click the blob in one window and move the mouse cursor off it (and off the scroll bar, as well as off the whole window), I can control the movement of the scroll blob from anywhere on the desktop. If I release the mouse button, the blob will stay where I left it.

My testing setting was WindowMaker running Opera and some tk 1 and 2 applications. All of them behave the same way.

For scrolling in general, I prefer the three button mouse (from Sun) I'm still using because I can't stand scroll wheels: They have the same "problem of arbitrary chosen scroll step", they are unprecise, make the window concent move in an unconfortable way and are unhealthy to the hand. So I press the middle mouse button and move the mouse in Y direction. I can scroll as slow or as fast as I want to. Needless to say that this doesn't require the window to be scrolled to have be in the foreground. Because of "focus follows mouse", I can, for example, leave my Opera window, scroll the text in the editor that is "beneath" the Opera window, and return the focus to the Opera window afterwards. That's quite handy in situations where you want to write in one window which you intend to be in the foreground, and scroll in another window that you don't want to cover the window you're writing in.

Reply Score: 2