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
_______________________________________________ pspp-dev mailing list [email protected] https://lists.gnu.org/mailman/listinfo/pspp-dev
