[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: 01 Apr 2003 12:48:48 -0500

On Mon, 2003-03-31 at 19:28, Luc Teirlinck wrote:
> Owen Taylor wrote:
>    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.
> I believe that this all boils down to the difference between (1) a
> character and (2) a pixel based philosophy.  For efficiency reasons,
> Emacs has no choice but to adopt (1).  Given that, it should do it
> consistently, otherwise things would become unpredictable.
> For (1) the thumb indicates the percentage of total "content"
> contained in the part of the buffer that is represented above, on and
> below the screen.  I believe that for (2) the thumb indicates how much
> more upward and downward scrolling is possible, regardless of how much
> extra content that is going to bring into view.
> Start with an empty buffer in a window that has room for 60 lines of
> regular character size and type:
> I believe that according to (1) the thumb should still cover the
> entire length of the scrollbar, but according to (2), it should only
> cover the top 60/61 of the scrollbar.  That is because there is now
> one extra screen line we can scroll down to and according to the
> visually based philosophy of (2), that matters.  According to the
> character based philosophy of (1), there are no extra characters that
> can be brought into view, even though extra scrolling is possible.
> Now scroll the second line to the top.  One screen line, two
> characters, scrolled of the screen.  We still have one third of the
> characters on the screen, so for (1), the thumb should occupy the
> bottom one third.  This is exactly what happens for the native
> scrollbar.  (I do not see why the knob should "pop out of the trough".
> The overscrolled piece contains no characters, so according to (1) its
> size is 0, it does not really "exist", it is an optical illusion.)
> For (2), I believe the thumb should occupy the bottom 60/61 of the
> scrollbar.  Actually, I believe that for (2) mere scrolling should not
> change the size of the thumb.
> I believe that it is correct for the default behavior of GTK to be
> pixel based, since it is more "intuitive" and covers the needs of more
> applications.  I believe that the question is whether somehow one
> could increase the "customizability" of the GTK scrollbar, to make it
> possible, to have it, within Emacs, better approximate the native
> scrollbar, without negatively affecting its interaction with
> applications that want a pixel based behavior.  Alternatively, people
> who prefer the consistently character based behavior (compared, not
> with a consistently pixel based philosophy, but with some inconsistent
> and unpredictable mixture) could use the native scrollbar (as I do).

While with your character based philosophy, you've described a perfectly
consistent visual model, I don't think it corresponds to workable
control for manipulation with the mouse.

This is most obvious in the case where you run into the minimum
scrollbar size. In the theme I'm using, the minimum scrollbar
size is 30 pixels.

So, all scroll positions that involve the first line being within
3% (30/1000) of the end of the buffer map into the exact same thumb
appearance. Overscrolling a buffer of more than a few thousand
lines with the mouse would not be possible.

But I'd say that you basically have the same problem even for
small buffers. If the scrollbar occupies the entire scrollbar
trough, dragging it downward doesn't correspond to any physical
motion of a scrollbar thumb. If you want that mouse action
to be possible, I'd argue that you really shouldn't use a control
that looks like it has real physical presence - something like 
the Emacs native scrollbar is more correct.


reply via email to

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