Re: start-editing signal?

[Allin Cottrell <cottrell wfu edu>]

On Mon, 24 Sep 2007, Kristian Rietveld wrote:

> On Fri, Sep 21, 2007 at 06:05:15PM -0400, Allin Cottrell wrote:
> > My expectation: the unfinished edit will still be in place. 
> > 
> > Actual behaviour: the "bottles of coke" cell is as it was before I 
> > started; my edit-in-progress is gone.
> > 
> > This may not be a bug as such, but I would like to know if there's 
> > a way of preserving the state of the cell-editing process, in face 
> > of the treeview window temporarily losing focus.
> 
> The behavior you describe is indeed the current behavior in GTK+ 
> >= 2.10 (and actually has some kind of history, but I won't 
> bother you with that ;).

OK, thanks.  I've now updated myself on some of the history via 
bugzilla.

> At this moment there is no code in GTK+ to automatically 
> preserve the value on focus out.  However, since there are 
> multiple different cases in which a focus-out should commit the 
> new value and also a lot of cases in which a focus-out should 
> *not* commit the new value, we are thinking of adding a property 
> to GtkCellRendererText which will control whether the input the 
> user has entered should be committed on focus-out or not.

I haven't studied all the reports on this, but I have looked at 
several of them.  I'll venture this opinion:

The default behavior should just be to preserve state (the edit 
remains in progress; it is neither automatically finalized nor 
automatically destroyed).  Isn't this what users generally expect 
of any GUI element that temporarily loses focus?  Surely loss of 
focus should not, of itself and in general, DO anything, either 
positive (commit the edit) or negative (lose the edit).

Nonetheless, there's at least one sort of case where a focus-out 
probably should be _associated_ with finalizing the edit, namely 
if the user moves the pointer from a treeview cell to click on a 
GUI element such as an "OK" button, which has the obvious 
interpretation of finalizing things (even if the edit has not been 
"technically" committed by pressing Return).

In the latter case, though, the pertinent aspect is not the loss 
of focus on the treeview per se, but rather the clicking on "OK" 
(or similar).  So shouldn't this be handled by a specifically 
coded callback?  Since GTK+ 2.6 we can attach to the 
"editing-started" signal.  This gives the means to implement the 
following:

* When OK is clicked (or whatever), see if editing of a cell is in 
progress.  If it is, commit the edit before proceeding, if this 
seems like the sensible thing to do.  (This obviously requires 
that the edit-in-progress is _not_ destroyed by the loss of 
focus.)

To my mind, this makes more sense than implementing an automatic 
"commit when focus is lost" routine.  Loss of focus may be 
correlated with circumstances where we want to commit an edit, but 
it's not logically connected.

Allin Cottrell