emacs-devel
[Top][All Lists]
Advanced

[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: 27 Mar 2003 10:48:42 -0500

On Wed, 2003-03-26 at 22:29, Richard Stallman wrote:
>     > I understand why the scrollbar thumb is shorter than I think it
>     > should be: to allow for placing the last line of the buffer in the
>     > top line of the window.
>     > 
>     > But still, I'm not so happy with the current look of the scrollbar.
>     > It confuses me quite a bit.  Is there no way to make the thumb extend
>     > to the bottom of the scrollbar area when end of buffer is visible, and
>     > yet to also allow scrolling further down so that the last line of the
>     > buffer can be moved to the top of the window?
> 
>     Not really.  The code in Emacs does not specify the length of the
>     thumb, GTK calculates it.  Emacs tells GTK how big the buffer is, how
>     big a page is and where we are in the buffer.
> 
> What happens if the app specifies a position that is less than one
> page away from the end?  Is that considered invalid?
> 
> 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.
>
>     When GTK decides that the thumb extends to the bottom it will not
>     emit events for anymore downwards motion with the mouse, only upwards.
> 
> Perhaps GTK should have an option so the app can let the thumb move
> further down.  What do people think of that?

Thoughts here, in no particular order:

 * 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)

   It's very easily in emacs's default configuration currently to 
   accidentally create text files with lots of trailing blank lines
   since there is no visual differentiation between blank lines and
   overscrolled space.

   (Emacs-21.2 with Xaw3d seems to be just buggy ... if the user drags
   the thumb of the scrollbar past the end of the buffer it shrinks
   to a smaller size and doesn't come back.)

 * 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)

 * There have been some somewhat similar requests; Gnumeric (I've
   CC'ed Jody Goldberg in case he has comments) goes to some extensive
   hack lengths so that you can click on the down arrow in the scrollbar
   and add extra blank lines. (You can also extend the area by
   cursoring past the ends of the buffer.) However, differing from the
   Emacs behavior:
 
    - 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.

    - When you scroll back up, the extra space vanishes.

   I wonder if we added some clean option to GTK+ to allow this 
   behavior, whether it would satisfy the requirements of Emacs? 
   The main difference is that you can't, by dragging the scrollbar,
   position past the end of the buffer. You would need to do 
   it by clicking on the down arrow (middle button goes down a page),
   or by keyboard commands such as C-l.
   
   (Note that Emacs could already implement this behavior for handling
   programmatic overscrolling already ... it's only the clicking
   on the down-arrow part that requires hacks in gnumeric.)
 
Regards,
                                                 Owen






reply via email to

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