[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Sheet replacement discussions
From: |
John Darrington |
Subject: |
Re: Sheet replacement discussions |
Date: |
Fri, 8 Jan 2016 14:10:23 +0100 |
User-agent: |
Mutt/1.5.21 (2010-09-15) |
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