Re: Scrollbar bug on OS X

[David Kastrup <dak@gnu.org>]

Miles Bader <snogglethorpe@gmail.com> writes:

> On Apr 6, 2005 11:32 PM, David Reitter <david.reitter@gmail.com> wrote:
>> that I'd like to implement in order to conform to standards in my
>> environment, the vertical slider size shows a proportion of _ displayed
>> lines_ not document characters or real lines (those that end with a CR
>> or LF). Whether that is better or not, I don't know, but what I do know
>> is that a) "less visual change on the screen is more", and that b) both
>> Windows and Mac software has sliders with a stable size.
>
> The only way I can see to truly have stable scroll-bar size is to
> base the size calculation on displayed pixels (lines are not
> necessarily a constant height, so the number of displayed lines is
> not a fixed proportion of total lines in the document).

I think you are laboring under the delusion that the scroll bar
actually displays something sensible, namely that mouse-2 exactly at
the bottom of the slider will take you exactly one page of screen
material further.  I think you'll find that users are much less
surprised if this goal is not exactly established than if the slider
grows and shrinks in size.  So the solution is to base the slider size
on some more-or-less sensible metric like lines-in-file (where
available) to lines-on-screen, and anyway, don't muck with it while
dragging.

> I'm curious how _any_ program manages to do this calculation in a
> reasonable amount of time; do they really lay-out the _entire_
> document ahead of time?  Do they use some sort of heuristic instead?
> What happens when the heuristic fails?

What should happen?  The user will correct over/undershoot, probably
not even considering that the computer could be at fault.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum