Re: gtk3: Replaced PsppSheetView with GtkTreeView for the variables window

[Friedrich Beckmann]

Am 11.12.2015 um 07:10 schrieb John Darrington <address@hidden>
>     The only real issue with GtkTreeView is that it doesn't efficiently
>     handle large data sets.  It uses O(n) time to deal with a sheet with n
>     rows or n columns.  It's fine for small data sets but with a million
>     rows it falls over.
> 
> Oh I think I remember now.  As I recall it, there is no problem with large 
> numbers of rows,
> so long as the "fixed-row-height" property is set.  The problem comes with 
> large numbers
> of columns (unfortunately there is no corresponding "fixed-column-width" 
> property).  This
> is why Ben invented the PsppireColumnFacade thing.
> 


Hi John, hi Ben,

i played with the grid.sps to create two test cases:

a) 50000 variables, 100 cases

In my current build, this renders so slowly, that it is unusable in the data 
view (which I did not change). I started psppire with grid.sav as argument on 
the command line. The startup time is
2:10 : black output window opens
2:30 : black data window opens, output window rendered
30 minutes until the data window is rendered
Scrolling / Editing the gtktreeview based variable window is o.k, i.e. with 
50000 rows.

I compared this to the the pspp-dev version in macports (gtk3 withouth my 
changes and some recent commits) and there is the same slow behavior.

b) 100000 cases, 500 variables

Startup is instantaneous. Scrolling/Editing is o.k. in data and variable window.

It seems that the current PsppSheetView is also slow with a large number of 
columns. I did not check this in the current stable gtk2 version.

Would it be o.k. if we will have to live with slow behavior with a large number 
of variables? Assuming that we might not even have a chance to change that with 
gtktreeview. (Except proposing an idea for the gnome guys.)

> Here is where I suggest we go from here:
> 
> 1. Let us replace ALL instances of PsppSheetView with GtkTreeView as you
>   have done for the variable sheet, and see what still works and what doesn’t.

> 
> 2. Let us find out which of the non-working features can be made to work
>   again using Gtk+3
> 
> 3. Of those which we can't get to work, we will make a decision if we can
>   live without them.
> 


Of course the final goal is to get rid of the PsppSheetView also in the data 
window. Maybe we can do some analysis with respect to your points 2 and 3 
already based on the variable window implementation because I think we need a 
decision regarding the UI behavior. At the moment I have

a) a first click selects the row and a second click changes the cell to edit 
mode
b) a double-click starts the dialog box for editing the Type, ValueLabels and 
Missing column. No previous selection required.

This uses the activation callback to open the dialog boxes. I think it is not a 
good idea to deviate too much from the default ui handling of the tree view 
because it may break other things (maybe drag and drop?) and interferes with 
the selection process.  A custom cellrenderer for the Type, ValueLabel and 
Missing rows may make it possible to start the editing dialog boxes also on a 
single click. But the Type dialog does in fact change data in more than one 
column - so it will deviate from the cell renderer idea with the chance that 
this is not possible.

But assuming the described behavior above, is this o.k? Would this be o.k. also 
in the data editor window? For me it would be more important that I can enter 
data in the column with a sequence of:  typing, press enter, typing, press 
enter. At the moment I have:

Enter (start editing)
Typing (edit)
Enter (stop editing)
Cursor Down (go to cell below)
Enter (start editing)
Typing
Enter
Cursor Down
…

I have not looked into it but as an example: That would drive me crazy.

> Maybe we should start a branch to do this work.

I pushed a remote branch „treeview".

Friedrich

signature.asc
Description: Message signed with OpenPGP using GPGMail