Re: New sheet implementation possibilities

[John Darrington]

Thanks for the feedback Friedrich,

The demo I posted, was just that - a demo.  Many of the things you mention 
would indeed have to 
be improved.  I was hoping to demonstrate how a lightweight widget could 
efficiently display 
(and edit) huge amounts of data without getting overcomplicated.

On Mon, Jan 04, 2016 at 07:12:39PM +0100, Friedrich Beckmann wrote:
     Hi John,
     
     this is a very nice demo! I also investigated some ideas for the sheet 
view. I
     looked into the idea to restrict the number of columns in gtktreeview and 
just change
     the displayed data based on scrolling. A demo is here:
     
     https://github.com/fredowski/lazytree.git 
<https://github.com/fredowski/lazytree.git>
     
     So this is based on the same idea as Timms demo. I noticed that the 
selection in
     gtktreeview is row based and I was too stupid to figure out a way to 
select a column/row
     area as in a spreadsheet. Finally I came to the same conclusion as you 
that it might
     be easier to start something more or less from scratch??? 
     
     I guess the core idea is to have only a small number of actual rendering 
widgets with
     possibly a huge data store behind that. You do this in your jmd-sheet-body 
draw method
     based on the cell_renderer_text. The actual rendering rectangle geometry 
is derived from 
     the horizontal and vertical sheet-axis. And there it is derived from the 
widgets that you
     inject with the cell_fill_function from the axis-model. The axis can 
contain a mixture of all
     kinds of widgets. In my understanding this is the core idea of Timm. Timms 
row based
     original idea allows the rendering of data with all kinds of different 
widgets for each column. 
     In that sense it is close to the column idea of gtktreeview. Your proposal
     has a fixed cell_renderer_text for the body while there is the full Timms 
flexibility in the
     vertical and horizontal axis rendering. 

Well in my quick demo, I have just a single GtkCellRendererText.  But there is 
no reason why one cannot
have other renderers too, depending on which cell is displayed.  For example in 
our variable sheet we 
might want a GtkCellRenderSpinButton for some of the columns.  It might also be 
a good idea to write
our own CellRenderer to cope with displaying Value Labels.
     
     I have the impression that this is a bit twisted. Full flexibility for the 
axis rendering with no
     flexibility in the body rendering. Maybe we could get rid of the axis 
alltogether and just render
     the case data with your body rendering method. Then the problem left is to 
get the required
     rectangle sizes for the cell_renderer. For column and row headers (your 
axis) I would use the same
     method, i.e. no widgets.

Like you say, the body is inflexible as I presented it - and that would have to 
be improved - but it
wasn't my first priority.

     Tree Model Interface
     ================
     
     When I did my experiments I found the abstraction of gtktreeview with the 
model and the view
     very nice. So I would use the the tree_model_interface to access the data. 
You might have a look
     at the 
     
     https://github.com/fredowski/lazytree/blob/master/lazystore.c 
<https://github.com/fredowski/lazytree/blob/master/lazystore.c> 
     
     which I think could be a basis to provide the case data. gtktreeview 
allows a relation between different
     properties of the cell renderers to data in the store. I think for us a 
direct relation of the data to the
     ???text??? property of the cell renderer would be sufficient.

I haven't looked at your code yet.  Currently I'm of the opinion that 
GtkTreeView is
too complex to satisfy some of our needs (it assumes that we want to present 
tree like structures) and at the
same time it does not fit some of our other needs (for example there is no 
simple way to get row headers on the 
left hand side).  

     
     Data kept inside the View
     ======================
     
     I think there is some data required for the rendering that is kept inside 
the view which
     can at best only initially be derived from the case data.

Obviously if the sheet is to be O(1) in space requirements, we cannot keep per 
row/column/cell information in the view.
     
     - column width (when manually changing the width)

For the case of pspp - this information is already in the model.  Each variable 
has a "display width" property.
I agree that is not the way I would have designed it - but that is what we have.

     - current selection (full column, full row, cell range, all)
     - cell which is currently edited

Yes.  They certainly belong to the view.


     
     Cell Editing
     =========
     
     The cell_renderer user functions for signals like ???editing-started??? 
only contain the ???path??? which
     contains the row information. To get the column information, the method 
used in pspp and described
     here: 
https://en.wikibooks.org/wiki/GTK%2B_By_Example/Tree_View/Editable_Cells 
<https://en.wikibooks.org/wiki/GTK+_By_Example/Tree_View/Editable_Cells> could 
be used.
     You have redefined ???path??? as information containing row and column 
information. Maybe that could be
     an alternative but I would consider to comply to the gtktreeview/treemodel 
interpretation. In your demo
     you have moved the whole filling and positioning of the GtkEntry in the 
???editing-started??? callback. I would
     stick to the gtktreeview method that positioning and default filling of 
the ???text??? property should be done
     inside the sheet-body where also the button-press is evaluated. You have 
derived body-sheet from 
     drawing area. Maybe it could be derived from gtklayout and then there is 
no need for overlay?


You are right.  The GtkOverlay idea was somewhat experimental.  There might be 
better ways to do it.
     
     Scrolling
     ======
     
     I would implement the scrollable interface. 

Yes.  I will to that (when I get time).

     
     Missing
     ======
     
     - Selecting/focussing based on key entry. Needs all the key handling parts 
as in gtktreeview.
     - Selecting whole columns, rows and all cells via clicking on row/column 
headers.
     - Selecting cell ranges via mouse.
     - Some interface the retrieve / change the selection.
     - Column width changes via mouse.
     - View updates when data in model is changed. I would stick to the 
treemodel interface signals.
     

Yes.  all those features would need to be done before we could use my demo in 
Psppire (if we decide to 
do that).


Thanks for looking at this.  I will try to look at what you have done tomorrow 
and give you my thoughts.

J'
     

-- 
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