Re: Gtk scrollbar: thumb too short

[Owen Taylor <otaylor@redhat.com>]

On Fri, 2003-03-28 at 10:20, Richard Stallman wrote:
>      * I've always found the emacs behavior with respect to the end of the
>        buffer quite confusing personally... I think it would be far
>        less confusing if the region that was scrolled was actually
>        confined to the lines of the buffer (or maybe lines in buffer + 1)
> 
> If you mean that it would be impossible for the end of the buffer to
> be located above the last line of the window, that would be taking
> away a feature that users are accustomed to.  We can't do that.

Was just an offhand comment :-) I didn't really expect it to be
acted on.

>      * Allowing dragging the scrollbar thumb past the end of the 
>        trough is something I'm quite hesitant to do:
> 
> 	- It will look like a bug to the user
> 	- Some themes may not be able to handle such a case nicely (think
> 	  of a theme where the stepper arrows are round circles in the
> 	  trough instead of being as wide as the trough ... in that
> 	  case the thumb can't simply be truncated by the stepper arrow)
> 
> It isn't a bug, though--and what else should the scroll bar do?
> What happens in those themes will be logical, and will show that
> the current visible window extends past the end of the text.

Just because something makes logical sense doesn't mean it will make
sense to users. But my concern is more:

 - It will be a confusing visual mess.
 - The visual representation won't correspond to the users ability
   to click on the scrollbar. (The ability to click on the arrow
   is not affected by the theme, just the visual representation.)
 - I suspect that many themes will simply not draw it correctly.

> 	- The extra blank lines actually extend the scrollable space - that
> 	  is, the thumb is always confined to the trough, it just shrinks
> 	  to indicate the longer scrollbar space.
> 
> In Emacs, these aren't "extra blank lines".  Emacs doesn't extend
> the buffer contents to reach the bottom of the window.
> The Gnumeric behavior isn't right for Emacs.
> 
> The GUI for a program should reflect the data in the program,
> not vice versa.

I think there is a strong case to be made that the length of the
scrollbar trough is

 MAX (length of document, maximum visible position)

rather than simple the length of the document. Consider the case
where the document is shorter than the screen height. In that case,
there is a strong expectation that the thumb extends the entire
length of the trough, and Emacs does that currently.

If you _didn't_ do that, then you'd have a scrollbar that only
occupies part of the trough but that it was impossible to drag
up and down. While that might make logical sense, it would be
highly confusing.

So if this interpretation of the trough length corresponding
to:

 MAX (length of document, maximum visible position)

is used for documents shorter than the screen, I don't see a
reason why it can't be used for the case of overscrolling as
well. The main difficulty would be when to take the overscrolled
area out of the trough size computation... usually you
want to do it immediately, but when the user is dragging the
scrollbar, probably not until they release the mouse.

To do that with GTK+ currently, is a bit of a hack, you
have to connect to the ::button-release-event signal on the
scrollbar. But I think it would be a reasonable RFE for GTK+
to have some clean way of finding out when the drag finishes.

Regards,
                                       Owen