Re: gtk scroll bar deficiency

[Stefan Monnier]

> I just built emacs with gtk for the first time and I was struck by the
> change in the scroll bar behavior (specifically, the location of the
> sliding "scroll thing" - what is its official name anyway?).

Some toolkits call it the "thumb".

> before: when the whole buffer is visible, the scroll thing in the bar
> occupies the whole scroll bar (clearly indicating that everything is
> visible); when the bottom of the buffer is visible, the scroll thing is
> at the bottom of the scroll bar. this is also the behavior of gedit,
> firefox, openoffice, gnumeric et al, and I like it.

> now: when the whole buffer is visible (more generally, when the bottom
> is visible), the scroll thing does not reach the bottom of the scroll
> bar - you can scroll down and, as the bottom of the buffer scrolls up,
> the scroll thing reaches the bottom of scroll bar (while decreasing in
> its size). this is the behavior of vim, and I hate it.

> is this change intentional?
> it looks like a bug to me...

I'm pretty sure it's intentional.  It's not perfect, but the perfect
behavior (which you get with the non-toolkit build) tends to be difficult to
get with current toolkits because toolkit writers are boneheaded: they
prevent applications from doing some very useful things in order to force
them into a predefined mould which of course doesn't fit all.


        Stefan


PS: Basically, they want to enforce limitations of the physical metaphor,
rather than let people benefit from the fact that it's only a metaphor and
thus doesn't need to suffer from the same limits.  Soon they'll ask for
mouses with feedback so the user has to make a physical effort proportional
to the size of the text/window when sliding the thumb.  Next thing you know,
the scrollbars will wear out and will need regular maintenance so they don't
get wedged.