[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Gtk scrollbar: thumb too short

From: Owen Taylor
Subject: Re: Gtk scrollbar: thumb too short
Date: 31 Mar 2003 13:12:07 -0500

On Sun, 2003-03-30 at 14:24, Richard Stallman wrote:
>     An observation I'd make is that a scrollbar really encodes two
>     things:
>      - A value
>      - A percentage of a total size
>     If we look at the scrollbar on the screen, we have:
>      v = thumb_start / (trough_pixels - thumb_pixels)
>      p = thumb_pixels / trough_pixels
> 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.

But in more complicated cases, your approach isn't possible. The
normal situation where this comes up in GTK+ is when the thumb
is clamped to its minimum size. 

>     For the normal GTK+ case these two quantities are related to the
>     document size.
>      v = start_of_visible / MAX (size_of_visible, size_of_document) - 
> size_of_visible
> thumb_start / trough_pixels normally corresponds to
> start_of_visible / MAX (size_of_visible, size_of_document)
> If this relationship continues to apply when Emacs overscrolls,
> you get the behavior I have asked for.

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. As discussed earlier,
   this will cause drawing problems, and also may cause
   problems for the ability of the user to click and drag
   on the thumb.

   The scrollbar models a physical system where there is a
   knob slid along a trough. If in the physical system 
   (a stereo component say), the knob popped out of the trough
   on the physical system, it would be a sign of shoddy 
   workmanship. I think the same holds for the onscreen case.

 - 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.

> I think of the scroll bar as showing how the document is divided into
> three parts: the part above the screen, the part on the screen, and
> the part below the screen.  The sizes of the three parts of the scroll
> bar are in proportion to those three parts of the document.
> When Emacs overscrolls, the last part of the document has negative
> size.  Properly speaking, the thumb should extend beyond the end of
> the trough.  Alas, that is impossible.  The Emacs 20.7 behavior is the
> closest possible approximation.

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. While you may think of the scrollbar as
a miniature view of the document, it is also presented
to the user as a physical control, with obvious limits as
to how far the scrollbar can be dragged.

You have to decide whether dragging the scrollbar to the bottom:

 - Scrolls to last page of the document
 - Scrolls to the maximally overscrolled position (one line
   at the top of the screeen)

(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
than something where the user can just drag the scrollbar down
as far as it can go quickly.)


reply via email to

[Prev in Thread] Current Thread [Next in Thread]