Re: New sheet implementation possibilities

[Friedrich Beckmann]

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

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. 

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.

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 

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.

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.

- column width (when manually changing the width)

- current selection (full column, full row, cell range, all)

- cell which is currently edited

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

Scrolling

======

I would implement the scrollable interface. 

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.

I am currently changing the lazytreeview in that direction. I will send you an update once I have something

to see.

Happy New Year!

Friedrich

Am 03.01.2016 um 21:14 schrieb John Darrington <address@hidden>:

Based on recent conversations, I am of the opinion that the listbox approach
(which I linked to earlier) is likely to be better in the long term than
anything based on GtkTreeView

Accordingly I have hacked up a demo based on that code.  This shows how a
sheet can be created with an arbitrary number of rows and columns and in
constant time and space.

If you are interested, check it out at http://darrington.wattle.id.au/efficient-sheet-0.0.tar.gz


The nice thing is, that it is O(1) in the number of rows and columns (assuming that
the total rows/columns exceed the number of visible rows/columns).


The big question of course, is how much effort it will take to get it to a
state that it'll fit into pspp.


Comments and feedback welcome.