Sheet replacement discussions

[John Darrington]

Fritz and I had a very interesting face to face discussion about the psppire
sheet and what to do about it.  Thanks for your hospitality and the beer Fritz!

Fritz was kind enough to point out a number of places where my code was
accessing "private" data without proper encapsulation.

He also showed me some rather nice possibilities for rendering things
onto a spreadsheet-like widget which I think we could use.  I think his
approach of using a GtkLayout and adding  the CellRenderer to that is 
preferable to my approach of a GtkOverlay.
Also I think the Gtk3 concept of "Gestures" will make a lot of code easier
which we previously had to manage by GdkEvents and a state machine - that
was very error prone.

I'm hopeful we'll be able to use these ideas to implement features like
- reordering variables by dragging them.
- adjusting column widths
- selecting multiple columns/rows


We don't see eye to eye on a few issues:

I am of the opinion that the  most elegant way to construct the sheet
is to have a separate sub-object representing the geometry of the 
rows and columns (what I have called the "axes" in my implementation).
These objects contain the buttons for the row/column headers and determine
the position and size of the respective rows/columns.  One advantage of
this approach is that it makes the "split window" feature easier - we
have a 1:many relationship between the axis and body.  If the geometry changes,
then I think it better for the axis to broadcast the changes to the sheet
body, rather than for each sheet forcing its changes on the axis.  I think Fritz
prefers the latter approach.

Fritz suggested that we standardize on the GtkTreeModel as the model for our
sheet.  That sounds attractive except for one big problem:  The GtkTreeModel
cannot perform random access into its rows - it can only access them 
sequentially
via a GtkTreeIter.   That means refreshing a view will be O(n) which we
want to avoid if possible.  Obviously in some cases (retreiving data from a 
dataset)
we cannot avoid it.   But I think it will be unacceptable for a SPSS dictionary 
with say 2500 variables (some people use such datasets!) to have to iterate 
through
all 2500 items when the sheet is scolled to the bottom of the variable view.
Instead, we want the best case model to work in O(1) time.

Finally I don't think it appropriate that the text displayed in the row/column
headers should be part of the data model - at least they should not be part of 
the
*same* data model which contains the contents of the cells.  The column titles
are metadata - not "real" data and the two should not be treated identically.

Of course, fate may prove me wrong on some or all of these issues.




-- 
Avoid eavesdropping.  Send strong encryted email.
PGP Public key ID: 1024D/2DE827B3 
fingerprint = 8797 A26D 0854 2EAB 0285  A290 8A67 719C 2DE8 27B3
See http://sks-keyservers.net or any PGP keyserver for public key.

signature.asc
Description: Digital signature