Re: Sheet replacement discussions

[Friedrich Beckmann]

    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