Re: Can I smooth scroll a TkTable? (was Re: Problems with grid, Scrolledwindow, and T

Jeff Hobbs wrote:
> ...
> As for the technical bits ... well, I make my life easy by not
> smooth scrolling.  All topleft coords start at an x,y that is set
> in the pre-calculated matrix of all row/col starts.  You will
> need to account for an offset here.  The clipping part is already
> handled on the other side, as I might not be able to draw the
> last row/col in full, so that code is there.
> ...

I guess I'm in over my head.  I've never worked in a C-based widget
before and TableDisplay is 800 lines long!  I can't grok it and I'm
sure it interacts with other code in ways I don't understand or
anticipate.  I don't mind doing the grunt work but I need an overview
and some direction.  Can Jeff or someone who has a bigger clue about
TkTable internals give me some guidance?  This is how I've started:

- Added a -scrollmode option in tkTable.c

- Added fields on the Table structure in tkTable.h to capture the
scroll info which is known in Table_ViewCmd() but, it seems, needed in
TableAdjustParams().

- Looked at TableAdjustParams() and considered that I think when I get
there and the scroll info indicates moving to a fraction of the height,
I need to compute:
.
.   topPixel = (tablePtr->rowStarts[tablePtr->rows-1] +
.                   tablePtr->rowPixels[tablePtr->rows-1]) * frac
.
At this point, I could store:
.
.   tablePtr->rowPixels[tablePtr->topRow] - topPixel
.
as an offset for displaying.  I think.

- Looked at TableDisplay() and given up 'cuz I don't see how to use
such an offset to adjust the display algorithm.

I fear that the right way to do this is to convert (rewrite?)
TableDisplay(), etc. to use pixels and then quantize pixels to the top
of a row or whatever elsewhere when I know what scrollmode I'm dealing
with.  That sounds touchy.

Feedback appreciated...

Chris