Re: Gtk scrollbar: thumb too short

[Owen Taylor]

On Tue, 2003-04-01 at 04:38, Richard Stallman wrote:
>     > That is unnecessarily complicated.  I think the position value that
>     > users see is thumb_start / trough_pixels.  That is much simpler
>     > and it is visually evident.
> 
>     For the normal case, these two approaches are the same.
> 
> The two models are mathematically equivalent in the normal case, but I
> conjecture that the simple one is the way users really understand it.
> In unusual cases, where the two models disagree, preserving the simple
> model will seem natural.  Preserving the complex model will seem
> unnatural.

Your model is not simple either - you are just making it sound simple
by neglecting the fact that there is some minimum size that you
can make the scrollbar thumb. When the scrollbar is at that 
minimum size, that must correspond to the bottom scroll position.
So, there is a scale factor in your approach too.

>     But in more complicated cases, your approach isn't possible. 
> 
> Of course it is possible.  Emacs already does it, with some toolkits.

See above. Unless you allow the scrollbar to go down to 1 pixel or
less, which I don't think you do, there is non-simple scaling involved.

In fact, your doesn't work at all unless there is a difference between:
 
 - The minimum size the scrollbar thumb can under normal circumstances

 - The minimum size the scrollbar thumb can be be at the end of the   
   trough.

Because it's the difference between those two sizes that ends up 
representing the overscrolling for a sufficiently large buffer.

But GTK+ doesn't have two minimum sizes, it just has one minimum
size ... the minimum size that a theme can draw the scrollbar
thumb.

So, even if we modified GTK+ to allow dragging past the end position,
for more than medium-sized buffers, you'd still have to figure
out how to deal with the case where the scrollbar thumb couldn't
get smaller at the end of the document.

>     You get a situation where the correct size of the thumb cannot 
>     fit into the trough with that starting position, which gives
>     you two choices:
> 
>      - Make the thumb go out of the trough.
> 
> I think there is a misnunderstanding here.  Nobody proposed this.  You
> said that some themes might do this, as a consequence of how the code
> works; I responded it is no problem if they do.

Many messages ago, you said:

 My suggestion is to display a thumb that rises from the bottom of the
 scroll bar, but is shorter than normal, as if the bottom of the thumb
 were hidden beyond the end of the scroll bar.  Others may think 
 of a better way to indicate this situation.

I took that to understand that you wanted the bevelling drawn as
if the scrollbar thumb was actually extending past the bottom
of the scrollbar trough.

>      - Shrink the thumb to a smaller size than it should be.
>        While less of a problem than the previous approach,
>        it strikes me as a little strange. Also, you still have
>        to consider what happens when you reach some minimum 
>        size for the handlebar.
> 
> This is what should happen.  This is what Emacs already does
> on some platforms.  (What is the "handlebar"?)

"Thumb", sorry.

>     I'm not sure that presenting this simple model to the user
>     is compatible with allowing the user to drag the scrollbar thumb
>     to overscroll.
> 
> They must be compatible; they already work together on other
> platforms.  It is somewhat hard to grab the thumb when most of the
> thumb is off-screen, but it should not be impossible.
>
>     You have to decide whether dragging the scrollbar to the bottom:
> 
>      - Scrolls to last page of the document
> 
> Dragging it to the bottom of the trough should scroll to the last full
> page.  Dragging it beyond the bottom should show less than a full
> page.
> 
>     (Note that by allowing the user to drag the thumb to overscroll,
>     no matter how you do it, you make the operation of scrolling
>     to the last page of the document a precision operation rather
> 
> That is true, but the amount of precision required is no more than for
> scrolling at any other place in the document.  Emacs has worked this
> way for many years, and we have not heard a complaint.

I think scrolling to the end of the document is a more interesting
operation than scrolling to some other place in the document.

Actually, it would be interesting to know what percentage of emacs
users actually _drag_ the scrollbar to navigate in a document; it's
quite possible the primary use of the scrollbar is as a visual
indicator of where the current viewport is located within the
document. In which case, it's not clear to me that the scrollbar
is the right control at all.

For GTK+, I really want to preserve the idea that the scrollbar
consists of a thumb of some length that can be positioned between
two extremes - at the top of the trough and at the bottom of the
trough. For it to change length while dragging is a bit peculiar.
For it to go past the ends of the trough, either literally or
by shrinking as it is pushed against the end is completely outside
that model.

Regards,
                                             Owen