Do you know of a tweak to influence the scroll thumb release distance?

[NoelC]

A long time ago I developed a habit of grabbing a scroll bar thumb and pushing the mouse toward the end and beyond without too much care when I simply want to scroll the window all the way to the end. 

 

At one time, as I recall the mouse would remain captive no matter how far off the scroll thumb the pointer actually was.  This made this particular "gesture" valid.

 

Lately I find that pushing the mouse a ways off the end of the scroll bar causes the mouse to "lose its grip" on the scroll thumb, the scrolling operation to be aborted, and the scrolled window to return to its starting point.  I've seen some info online that implies the distance is 100 pixels.

 

When a window has been scrolling in real time, then it "jumps back" to where it started right about at the time I release the mouse too far from the end, I find that very disruptive to my train of thought.  I find anything that "automatically cancels" an operation I've initiated annoying; I believe anyone would.

 

My question is this:

 

Do you know of a setting that can be changed to increase the distance the window manager allows the cursor to move away from a scroll bar thumb with the left mouse button down before the thumb is automatically released? 

 

A setting to disable the behavior altogether would be fine as well.

 

Thanks in advance.

 

-Noel

[NoelC]

I'm starting to believe that whatever programmer thought of this annoying "feature" didn't think it needed a configuration option.    Or at least no one's found it yet.

 

I've found some additional discussions on the subject:

 

http://www.red-bean.com/kfogel/ms-scrollbar.html

 

http://ux.stackexchange.com/questions/55623/why-do-scrollbars-revert-to-original-scroll-distance-when-mouse-is-dragged-sidew

 

To me it seems like a violation of trust.  I clicked the mouse on something.  I expect the OS to consider that I'm holding on it the master input.

 

Some say they believe this behavior is implemented as a way for an unintended operation to be canceled, and that moving the mouse away from the scrollbar is the way to make that happen.  Maybe that's justifiable - but geez, make the distances programmable.  I say "distances" (plural) because it's possible that it might be sensible to allow more dragging off the end than off the side, though frankly I find it too sensitive right now in both dimensions.

 

-Noel

[jaclaz]

It is a known "issue" or "feature", and it is seemingly "by design".

 

I presume that changing your habit to use instead shift+click on the bottom part of the scrollbar is a no-no, right?

 

The behaviour has it's fans, however, JFYI:

http://www.red-bean.com/kfogel/scrollbar-redux.html

 

 

jaclaz

Edited August 4, 2014 by jaclaz

[NoelC]

I know how to work around the problem when I'm thinking about it.  Trouble is, when I'm "in the zone" - concentrating on the work and not thinking about being careful with the scroll bar I find myself using the method that leaves me frustrated.   

 

It's quite often a sideways scroll - for example trying to reach the end of some very long lines in a log via my text editor - which gives me a lot more room to go "too far" (I have 3 monitors on task).  I think maybe it was the addition of the 3rd monitor that's uncovered this.  I have both more vertical space and more horizontal space on my desktop, and windows don't tend to be placed as close to the edges..

 

Don't get me wrong - the ability to "undrag" a scroll thumb without having to undo isn't a bad idea.  But even if people want the ability to automatically lose their grip on the thumb, the threshold should be programmable, and it would be best if it could be made more sensitive to dragging off the side vs. the end.

 

-Noel

[jaclaz]

But even if people want the ability to automatically lose their grip on the thumb, the threshold should be programmable, and it would be best if it could be made more sensitive to dragging off the side vs. the end.

Yep .

Right now we have a "circle" with a given radius (that seemingly cannot be modified) and once the mouse exits this circle the "grip" is lost, having the radius changeable would be a first progress, and having the possibility of "stretching" the circle into an ellipse would be second step.

 

In the thread you referenced:

http://ux.stackexchange.com/questions/55623/why-do-scrollbars-revert-to-original-scroll-distance-when-mouse-is-dragged-sidew

 the radius has been measured to around 100 pixels, but most probably this depends on resolution of the display.

 

In any case it is the usual MS approach to tailored suits :

We made it this way, it is right, and the one-size-fits-all should fit you nicely, otherwise it is your responsibility to loose or gain weight (or get taller or shorter )as needed.

 

 

jaclaz

[NoelC]

The unsaid part is that the product would cost more if it's completely self-adjustable.

 

I believe that to be true, if you focus specifically on the support organization.  Thinking of extremes, if you released a "one size fits all" package with literally no configurability, it will be less expensive to support than one in which virtually everything is configurable by the end users.  Engineering might even agree that such a system is easier to build.

 

But both organizations, in their zeal to save effort (and thus money), conveniently forget that the process of dumbing down the system to further their goals actually reduces the value that the system provides.

 

There's a REASON that so many things were made configurable in the systems of the past.  It's because the engineers of the past realized that such configurability DOES add value.

 

 

I would gladly pay more - much more - for a truly professional operating system.  That's because I have a need for it.  I actually HAVE paid more, in the past (thinking of systems that ran on computers the size of buildings).  That Microsoft wants to abandon the realm of professional systems altogether in the pursuit of making toys for consumers is the crux of the problem.

 

 

P.S., I'm going to guess it's probably a square, not a circle, that defines the distance the mouse can travel from the thumb before capture is lost.  That would be easier to implement, and the same engineer who was too lazy to make it configurable probably wouldn't want to go look up the sqrt(x * x + y * y) formula for distance.

 

-Noel

Edited August 5, 2014 by NoelC

[jaclaz]

 

P.S., I'm going to guess it's probably a square, not a circle, that defines the distance the mouse can travel from the thumb before capture is lost.  That would be easier to implement, and the same engineer who was too lazy to make it configurable probably wouldn't want to go look up the sqrt(x * x + y * y) formula for distance.

Entirely possible.

 

Though, to be fair, in pseudo code you could have:

 

"square":

IF DeltaX>100 THEN GOTO :LOOSEGRIP

IF DeltaY>100 THEN GOTO :LOOSEGRIP

....

 

vs. "circle"

IF DeltaX*DeltaX+DeltaY*DeltaY> 20000 10000 THEN GOTO :LOOSEGRIP

or:

IF DeltaX^2+DeltaY^2> 20000 10000 THEN GOTO :LOOSEGRIP

avoiding the Square root by using the  sum of squares as comparison term, it remains to be seen if two IF conditions would be more or less efficient than the math functions used n the second.

 

The "ellipse" would need a more complex formula, but changing the "square" to a "rectangle" would be a snap.

 

jaclaz

Edited August 6, 2014 by jaclaz

[NoelC]

The number to check the sum of the squares against would need to be 10000 (100 squared), but yes, you have a grasp of the logic.

 

A Windows programmer might have inflated the rectangle that defines the scroll thumb by 200 in each dimension using InflateRect() then called PtInRect() to see if the mouse is in the vicinity.  It would have been slightly more difficult to determine the direction (more horizontal or vertical) and so we can assume they would be lazy and not try to do that.

 

Then some other programmer may or may not have come along and added code to handle screen scaling.  We can be sure it was someone's responsibility to update the common controls, but given the inconsistencies among them we can only guess how messy the code must be.

 

And a number of others who wanted their applications to work better than the norm, not finding the feature configurable, likely subclassed the scrollbar control in order to change the behavior so that the rectangle was larger.  This ensures that, while it might be more livable in some applications, it won't be consistent between them.

 

Apparently no one involved thought it would be a good idea to ask someone in charge to make the numbers programmable.  Perhaps even inside Microsoft it's impossible to know how to contact others inside Microsoft.  Or maybe they did find a way to ask but were met with a closed-off response.  Microsoft knows best, after all.

 

-Noel

Edited August 6, 2014 by NoelC

[jaclaz]

The number to check the sum of the squares against would need to be 10000 (100 squared), but yes, you have a grasp of the logic.

Yep, typo/mistake   , correcting previous post.

 

I seem to remember having found - while looking for this - reportds that actually Internet Explorer (at least in some versions) did not behave like described , which would be typical, just like most office applications (Word, Excel etc. not using the "normal" file open and file save/saveas dialogs).

This is one of the funny things about the good MS guys, they "precribe" something to all the world and then they themselves do another thing .

jaclaz

Edited August 6, 2014 by jaclaz

[NoelC]

Yes, there's no apparent desire for them to be consistent with their own standards/best practices.

 

Speaking of which, I guess this is related:  A while back I found another, different instance of "what I started doing with regard to scrolling was undone by the OS automatically"...

 

If I hover over the scroll bar in Word, and don't move the mouse, the scrollbar will self-disable after a short time and clicking the mouse to page up or down will stop being effective.

 

See my thread on THAT subject here:

 

http://answers.microsoft.com/en-us/office/forum/office_365hp-word/word-365-scroll-bar-becomes-unresponsive-after/7275cc93-28bb-4292-bb57-63874edea1ef

 

-Noel