Re: Addition to emacsbug.el

[Stefan]

>>> For GTK at least some compromise is needed.  Some themes have a minimum
>>> size for the thumb.  So if the thumb is at its minimum size
>>> the overscrolling with the thumb shrinking can't happen.
>> 
>> Huh?  Are you sure?  I'd expect that the display-size of the thumb is
>> "unrelated" to the size as specified by the C code.  What if your document
>> is made of 10 pages and your scrollbar is 40 pixels and your minimum thumb
>> size is 20 pixels, is GTK going to prevent you from seeing more than
>> 2 pages?

> No, but the 9 pages will be scrolled in 20 pixels.  So no precision
> scrolling is possible if you have many pages and a small window.  It is the
> same for any scroll bar, the minimum size is at least 1 pixel.  And if you
> have a window that is 40 pixels and the buffer is 1000 pages, you have to
> scroll through 999 pages in 39 pixels.  Basically the scroll bar is useless
> in this situation.

Yup.  So you agree it's actually not specific to the fact that some themes
have a minimum size for the thumb.  The problem is simply that Gtk makes
overscrolling "impossible", just like Xaw3d and Motif (used to) do.

>>> Otherwise we should do something else, be it your solution or the thumb
>>> shrinking one.
>> I don't know what is the "thumb shrinking" solution.

> I described previously in
> http://lists.gnu.org/archive/html/emacs-devel/2004-10/msg01300.html

Oh, I see.  That's more or less what Xaw3d used to use.
The problem with it was that the thumb was shrunk too late:
- the user moves the mouse past the bottom.
- the thumb is moved by Xaw3d to the bottom (and no further).
- the callback is called and Emacs finally gets a chance to change the thumb
  size (but it doesn't know how far the mouse has moved: it only knows that
  it's at least gotton to the bottom, so it doesn't know how much to shrink
  it).
- unless the user moves the mouse again, the position of the thumb
  is not updated to take into account the original "past the bottom"
  mouse movement.

So what often happened is that you'd move the mouse past the bottom and then
you'd have to wiggle it to get the callback to shrink the thumb little
by little.  Your suggestion to shrink it to 0 as soon as you hit the bottom
would indeed help: you'd only have to move the mouse once after
hitting bottom.

In the case of Xaw3d an additional problem is that the Xaw3d code ignore(d|s)
requests to change the size of the thumb while dragging (the xterm.c code
has/had some really ugly hacks that accessed internal variables of Xaw3d to
try and fool it into thinking it's not dragging).

>>> To change the thumb size means fiddling with the page size and the
>>> maximum values for the scroll bar.  Relating values back to a buffer
>>> position then becomes so much harder.  Not impossible, but certainly
>>> a lot of testing needs to be done.
>> 
>> Hmm... I'll trust you on that one because I obviously don't understand
>> the difficulty: the way the xterm.c code uses SB_MAX or equivalent as the
>> "maximum value" it would work exactly the same whether SB_MAX is
>> a constant
>> or not.

> If I change the maximum value, the thumb size changes.  I then also have to
> adjust the value otherwise the thumb changes position.  Also, page_size
> page_increment and step_increment has to be changed.  Obviously this
> is no more than to find a suitable algorithm, but the bad thing is that
> the thumb almost always jump a bit when these values are changed.

I'd think this algorithm is already written (to update the size and position
of the thumb after point movement or buffer modifications).  But as I said,
I don't actually know what I'm talking about, so please ignore me here.

> I used Xaw3d.  The point that bothered me is if I have to pages in
> a buffer, scrolling three lines involves a small mouse movement.
> If I have three lines in the buffer, scrolling three lines involves a very
> big mouse movement, even if I start with the mouse pointer in the same
> place in both cases.

If that's the only thing that bothered you with my Xaw3d code, I'm
flattered ;-).  After all, it's the desired behavior (and AFAICT this part
of the behavior is common to all scrollbar implementations, even for other
programs).


        Stefan