[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: John Darrington
Subject: Re: gtk3: Replaced PsppSheetView with GtkTreeView for the variables window
Date: Thu, 10 Dec 2015 19:12:36 +0100
User-agent: Mutt/1.5.21 (2010-09-15)

Hello Fritz, Great work.

If we can get rid of pspp-sheet-view altogether I would be very happy.

To put things in contrast, here is a bit of history of the sheet as I
recall it:

My first idea was to lift some code from Gnumeric and use that.  After
speaking to the Gnumeric developers they advised me that this wasn't
practical, and pointed my in the direction of a third party contrib
in the internet called GtkSheet (not part of any Gtk release, part appeared
to have been forked from a very early version of GtkList - a predecessor
of GtkTreeView).

GtkSheet worked barely.  Its biggest problem was that it did not
follow a model-view-controller paradigm.  Instead, the whole datasheet,
had to be copied into the widget.  This clearly wasn't acceptable for
us, so I spent a long time hacking it to work in the MVC paradigm.
This gave us relatively good results, but there was a lot of work 
maintaining it.

Later we tried, as you have done, to use GtkTreeView to replace GtkSheet.
We decided that it could not work exactly as we would like, so Ben
forked it, and the result is PsppSheetView what we have today.

I don't exactly recall the reasons why we decided that GtkTreeView didn't
satisfy our needs - perhaps it was to do with the rendering of the "special"
widgets in the Variable type,decimals and value labels columns - but maybe
whatever it was, they no longer apply now that we have moved to Gtk+3

Gtk today has things called GtkCellRenderers which might be able to help us
with what pspp-widget-facade.c has been doing to date.  There is also 
GtkGestureDrag which might help with the double/single click quandary.

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.

Maybe we should start a branch to do this work.

What do you think?


On Wed, Dec 09, 2015 at 08:19:02PM +0100, Friedrich Beckmann wrote:
     Am 19.05.2015 um 14:11 schrieb John Darrington <address@hidden>:
     > I'm hoping, that some future Gtk+ version will have a GtkTreeView widget 
     > (or some other widget) which is flexible enough that we don't have to 
     > maintain our own sheet widget.  If that happens, then most of the 
     > warning will go away.
     Hi John,
     I replaced the PsppSheetView with GtkTreeView in the variables window to 
see how it looks. Basically it works but there are some differences in user 
interaction. The GtkTreeView expects a first click on the cell to select the 
cell and then another click to edit the cell. My implementation for the dialog 
windows for Type, Value Label and Missing is based on the row-activate signal 
and requires that one does a double click on the cell to open the dialog. This 
is then different compared to editing the text cells like NAME, where just one 
click to select and a second single click to start editing is required.  
     It is possible to have the ?activate? also with just one click, but then 
this interferes with the selection process. Clicking on a TYPE cell to start 
the selection will open the dialog window. (See  
gtk_tree_view_set_activate_on_single_click in the data-editor.c changes)
     It is also possible to start editing with just one click by using the 
activate callback to do gtk_tree_view_set_cursor. However this also interferes 
with the selection process. (see on_row_activated ).
     I also thought about a new cell renderer for the dialog box type editing 
but the TYPE dialog box modifies data in several columns plus I am not too sure 
how I can end the editing inside the editing-started callback. Maybe this is 
not possible.
     Anyway, using the GtkTreeView in the way it is supposed to be used is 
different in the way the editing is activated. My ideas to start editing with 
just one click resulted in problems with the selection process. Here is a video 
link to see the GtkTreeView based behavior with lousy sound:
     Do you think we should change to GtkTreeView? 
     Attached is the patch with my changes including debugging printfs. So if 
you want to try it? I did this on MacOS with gtk3 18.5.3 via macports.

Avoid eavesdropping.  Send strong encryted email.
PGP Public key ID: 1024D/2DE827B3 
fingerprint = 8797 A26D 0854 2EAB 0285  A290 8A67 719C 2DE8 27B3
See or any PGP keyserver for public key.

Attachment: signature.asc
Description: Digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]