Re: Addition to emacsbug.el

[Jan D.]

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

> > If the shown portion of the buffer is small compared to the total 
> > size of
> > the buffer, I think the virtual page behaviour is OK.  After all, can 
> > you
> > see the difference between a thumb who has a height that is 1/30 of 
> > the
> > window height, or 1/31?
>
> Agreed: the exact size of the thumb doesn't matter that much.
>
> But I can usually still see whether the thumb is "at the bottom" or 
> whether
> there's still one or 2 pixels left, so as long as 1 pixels represents 
> about
> 20 lines the difference is "relevant" (i.e. 20 lines =~ 500 chars =>
> a buffer of about 500B * 1000 pixels = 500KB for my typical frames).
>
> By "relevant" I don't mean important, but just that it's not 100%
> negligeable.  I could probably happily live with the "virtual extra 
> page"
> for buffers as small as 50KB.

I haven't really tested to see where the threshold is for me, but I 
think
that sounds reasonable.

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

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


> > There is another thing I noticed about your patch.  If the buffer 
> > contains
> > three lines and the window is 34 lines, the thumb covers the whole 
> > window.
> > Now, if I start to scroll down putting the pointer somewhere at the 
> > top
> > of the thumb, I'll have to move down to half the window before one 
> > line
> > is actually scrolled.  Then down to 3/4 before the second line is 
> > scrolled
> > and finally to the bottom to get the third line to scroll.
>
> > Now, if I start with the pointer near the bottom of the thumb, the two
> > first lines are scrolled just by moving the pointer one pixel.
>
> > I think the amount you move the pointer should determine how many 
> > lines
> > are scrolled, not where you happen to put the pointer when you start.
> > Also, the amount to move for scrolling one line should be the same
> > regardless of the size of the buffer or the amount show.
>
> Well, obviously this actually depends on the toolkit in use (in Xaw3d, 
> the
> thumb is always moved to the mouse pointer during grab, so the 
> position of
> the mouse pointer is what matters, rather than the distance you move 
> it).
> What toolkit were you using in the above described case?
> My patch is only really tested with Xaw3d.

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.

> > The code shared is smaller than the code that differs, so I really 
> > don't
> > see the point.  But if the shared code could go into a function of its
> > own that would make sense.  For GTK it was convinient to have all code
> > that modifies the scroll bars in one file when changes had to be done.
>
> Well, I was hoping the code that differs could be reduced further (I 
> didn't
> have GTK installed when I did the merge, so I didn't get to check 
> whether
> it compiled, and I haven't tried to change the code to adapt to the 
> "squash
> thumb to 0-size during drag" to GTK: this change has reduced the
> code-difference between Xaw3d and Motif (and non-toolkit) to one or two
> lines only, so I'm hoping something similar can happen with GTK).

Actually it didn't compile, but there where minor tweaks (I think
it was that you called a static function in gtkutil.c from xterm.c).

Anyway, the GTK code section in your part is basically the functional 
equivalent what motif calls XmScrollBarSetValues.  Unfortunately, GTK 
has nothing similar.  So we could still keep that part in gtkutils.c 
and call it xg_scroll_bar_set_values or something.


        Jan D.