Re: Sheet replacement discussions

[John Darrington]

On Thu, Jan 07, 2016 at 10:48:56PM +0100, Friedrich Beckmann wrote:

     > 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.
     
     I remember that we both came to the same conclusion that the column width 
should
     be derived from the rendering result of the column header width as default 
width plus
     manual changes via mouse. Those manual adjustments should be possible per
     column. 

Yes.  The only way I can think of implementing this is to have a hash table of 
all the columns which have manual overrides.  Potentially the hash table could 
grow arbitrarily, but users will not make manual changes to thousands of columns
so in practise that need not be a problem.

     The row height should be derived fix for all rows from the rendering 
result of
     the row header height. 

Right, but if we allow columns to be of differing widths then it is no effort
to do the same for rows - even though we don't really need it.

     
     Displacement from adjustment, column/row number from adjustment and
     column width must of course be 100% aligned between the header axis and 
body.
     So we both think that this should be computed once. You compute this in 
the axes and
     the body asks for the results. Then you align the axes and the body 
widgets via
     GtkGrid such that the rendering is also visually aligned.
     
     I have not done the headers yet and my first idea was to render them in 
the GtkLayout
     right away. So in my view the difference is more related to the question 
if the rendering
     happens in several widgets which are strongly coupled or in one widget.

Yes.
     
     You mentioned it yesterday that reducing the size of a widget below its 
???minimal??? size
     is not easy. I looked a little bit into this yesterday and I didn???t find 
a simple method either.
     So it seems that this requires some clipping window? Therefore I thought 
it might
     be a way to render the headers also via cell_renderer where the clipping 
is already
     included. I had a glance at the GtkTreeView way and I think they use 
GdkWindows to clip
     the buttons.

I think it might be possible to write a special deriviative of GtkBin which 
clamps 
the dimensions in the size-allocate method.
     
     > 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.
     
     I think this is a misunderstanding. Assume you want to access row 5, 
column 15.
     See the code below summarized from
     
     https://github.com/fredowski/lazytree/blob/master/lazytreeview.c#L292
     
     GtkTreeIter iter;
     guint row = 5;
     guint col = 15;
     
     /* This translates an integer row number into an iter */
     gtk_tree_model_iter_nth_child (tree_view->model, &iter, NULL, row);
     /* This does the data access to row 5 column 15 */
     gtk_tree_model_get_value (tree_view->model, &iter, col, &val);
     
     
     This is a random access giving the value for row 5 and column 15 from the 
model, no?
     Maybe you assume that gtk_tree_model_iter_nth_child will traverse the 
model, but that
     is not the case. See:
     
     https://github.com/fredowski/lazytree/blob/master/lazystore.c#L280 
<https://github.com/fredowski/lazytree/blob/master/lazystore.c#L280>

Maybe you're right.  Thanks for setting me straight.  In that case, perhaps we 
can use
the GtkTreeModel.  

The only problem I see now, is that there needs to be a method to query the 
number of
columns.  GtkTreeModel assumes that all rows have variable numbers of columns 
whereas
we will require it to be fixed.
     
     > 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.
     
     Yes, there are good arguments for that. On the other hand we a have a 
strong linkage
     between column headers and the data in the column. If there is that strong 
linkage, then it might be safer
     to have the strict relation also in the data model. For example it should 
not be possible
     by design to have a different number of columns when you ask the body data 
model and the
     column header model. If a variable is removed, then the data and the 
header is removed because
     the belong together, right? Maybe it is easier to think of different 
interfaces to one data model.
     Then the data model would have a GtkTreeModel interface for the body data 
and a ColumnHeader Interface
     for the column header data.
     
Well there is strongish linkage in some instances.  For example, the column 
headers of the variable sheet are pretty strongly linked (but that might change
if and when we support "variable attributes" in the var sheet).  
The linkage between the column headers in the data sheet is less strong - it
is linked indirectly through the dataset's dictionary.   And the linkage between
the row headers and the data in the data sheet is non-existant - regardless of
how you reorder the data, the row headers should still read 0, 1, 2, 3, ...

Another reason for disliking this idea, is that it means extra work when 
creating
the model.  It would be nice to be able to take any arbitrary GtkTreeModel 
and display it in the sheet.  But if we go down that path, we either have to 
shift
the data right one column and down one row - then add the header data, or we
have to put all models in a wrapper model which does that for us.  It sounds 
like
a lot of work.


J'


     
     Fritz
     
     
     
     
     
     



-- 
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