Sticky columns/rows

[Kjetil Torgrim Homme <kjetilho ifi uio no>]

I just subscribed to this list, so I guess a "Thank you!" to all the
developers is in order :-)

One feature I'm missing from Excel is the ability to fix a row or
column so that it is always visible.  This is very useful when
entering data, when it is easy to forget which column is which once
you get to row 40 or so.  I notice that there is support for repeating
rows/columns onto the next sheet of paper in the Print dialog
(although it seems to be non-functional), I want this on the screen.
(Excel separates the two, too.)

I thought I'd implement it myself, but it doesn't seem trivial for me
as a newcomer to both Gnumeric and GTK code so I am looking for
advice.  As I understand it, Gnumeric always draws into a canvas, and
never knows how much of it is visible.  This means that I can't hack
the "sticky" code into, e.g., item_grid_draw(), since it has no
knowledge of screen appearance.  It seems to me that the general
solution needs to create several viewports onto the same sheet.

    A   B   C   D   E   F   G   H   I
   ___________________________________
  |___|___|#S#|___|___|___|___|___|___|
  |___|___|#t#|___|___|___|___|___|___|
  |___|___|#i#|___|___|___|___|___|___|
  |___|___|#c#|___|___|___|___|___|___|
  |___|___|#k#|___|___|___|___|___|___|
  |___|___|#y#|___|___|___|___|___|___|

In this example, column C is sticky.  When the user causes the
spreadsheet to scroll left (or the viewport to scroll right), first A
is removed from view, then B, then D, then E.  C is still visible.
Usually, only the leftmost column(s) or topmost row(s) will have this
property.

Anyway, one way of handling the situation when D should be removed is
to create a new canvas with only column C in it, shrinking the old
one, and inserting it.  Worst case, you will need one canvas along
each edge...  That will screw up the scroll bars and a lot of other
stuff, I guess.  Cursor movement will have to be coded strangely.

Another way might be to reset the visible bit dynamically (it will
need to be kept separate somehow, of course), updated from the
routines which move the viewpoint around.  The downside to this is
that the canvas not necessarily can blit the drawn cells, there needs
to be some invalidation mechanism.

Any other bright ideas?


Kjetil T.