''GPS'' - I decided to create this page, so that the Tcl community can fix the Tk scrollbar.  The code below demonstrates the bug, if the slider is moved.
----
 #!/usr/local/bin/wish8.3

 pack [scrollbar .s -command {.t yview}] -side right -fill y
 pack [text .t -yscrollcommand {.s set}] -side left

 for {set i 0} {$i < 300} {incr i} {
 .t insert insert $i
 }


 for {set i 0} {$i < 20} {incr i} {
 .t insert insert "$i\n"
 }

 for {set i 0} {$i < 300} {incr i} {
 .t insert insert $i
 }
----
''GPS'' - It would seem that the scrollbar slider height is not set properly.  Ideally the scrollbar should ask the widget being scrolled for the total number of lines or pixels, then that should be divided by the height of the area that the slider operates, which is subtracted from for the 3D border.  That should take care of the position.  The custom scrollbar code that I posted goes more in depth into this issue.  I'm going to get started studying the tkScrollbar C code.

''DKF'' - If the problem is what I think it is (that the scrollbar length changes radically as you move it) then the problem is not with the scrollbar itself, but rather with the text widget that does not seem to take into account the viewable area taken by each line when calculating the scrollbar size - it works in the logical domain only, and this only works reasonably when lines do not wrap.  To make things more fun, if you turn off text wrapping, increase the number of short lines in the middle by a good few (i.e. more than the number of lines in the viewable area), and add a horizontal scrollbar as well, you should find that as you scroll vertically, the size of the horizontal scrollbar changes...

''GPS'' - Now it makes sense that the problem is with the text widget.
----
''GPS'' - I've noticed the same problem in EZWGL, Lesstif, and whatever Wily uses (9 libs?), so this seems like a more common problem than I previously thought.
----
''DML'' - I need to have "scale-type" scrollbar instead of variable-height. So I'll have the "slider" of scrollbar be same height regardless of scrollbarred window  visual size and height. Just right now it's very hard to create such kind of scrollbar. Also it'll be better to be able to change height of arrows in scrollbar.
----
[Vince] - I've been thinking about this.  The text widget currently assumes each internal line occupies just one visible line, except for those which are actually visible, for which it knows the correct value.  This leads to the daft behaviour described above.  What if the widget instead calculated the ''average'' number of visible lines per internal line (based upon what it can see in the window), and then used that average as a multiplying factor for all the non-visible, unknown lines.  Of course this would not be perfect, but it would have three good points:

   * when all lines occupy one visible line the behaviour is unchanged
   * I believe in all cases it will be ''better'' than the existing algorithm (but still not perfect).
   * performance will be basically unchanged.

any thoughts?  Hmm -- further thought shows this might work ok in one direction, but then the calculation needs to be reversible, and it's not.