Re: Sheet replacement discussions

[Friedrich Beckmann]

Hi John,

thanks for summarizing our discussion. It was really nice! Some thoughts to your

summary below...

Am 07.01.2016 um 19:17 schrieb John Darrington <address@hidden>:

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.

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. The row height should be derived fix for all rows from the rendering result of 

the row header height. We do not assume that the cell rendering should have an influence

on the column width and row height. 

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.

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. 

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

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.  

Cheers!

Fritz

signature.asc
Description: Message signed with OpenPGP using GPGMail