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