>> 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.
Nice idea. > … 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. I don’t think that is right. The call is gtk_tree_model_get_n_colums (treemodel). See: https://github.com/fredowski/lazytree/blob/master/lazytreeview.c#L381 >>> 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. Maybe I just look at the sheet replacement more independent from pspp. I see a data store which provides the data via the GtkTreeModel Interface. Our new view can optionally display a row of this data as column headers which are rendered in a special way (not scrolling). It can also optionally display a column as row headers. Therefore you tell the view which row should be used as column header and which column should be used as row header data. By design there could not be a different number of column headers and columns for the data. This would be different from the way GtkTreeView does it. But in GtkTreeView there is a complex relation that you manually select which column in the data store provides which attribute of the cell_renderer, e.g. the displayed column 8 takes the content of column 3 in the data store as „text“ attribute and the content of column 51 as background color. Each column in the view uses possibly several columns in the data store for attributes. It is also possible that there are columns in the store which are not used in the view at all. This allows of course that you can have different views of the same store. After writing these two paragraphs I noticed that there is a good reason not access the column headers as a normal row. If we ever want to render a different type than G_TYPE_STRING, then the view would probably not know how to render a column header row if there is a G_TYPE_OBJECT inside… And in GListStore the type of each column is fixed, e.g. row 1 col 5 cannot provide a different type than row 15 col 5. So our view could not work with GListStore if we ever render other types than G_TYPE_STRING and want a column header. > 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, … You can argue that the row headers are strictly generated without any information relating to the cases. If we see it as in Excel with no/never any relation to the data, then it would be part of the view, right? Fritz
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ pspp-dev mailing list [email protected] https://lists.gnu.org/mailman/listinfo/pspp-dev
