Am 11.12.2015 um 07:10 schrieb John Darrington <[email protected]> > 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
_______________________________________________ pspp-dev mailing list [email protected] https://lists.gnu.org/mailman/listinfo/pspp-dev
