Re: start-editing signal?

[Dave Howorth <dhoworth mrc-lmb cam ac uk>]

Allin Cottrell wrote:
> 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).

Absolutely! I run my window manager with a 'focus follows mouse' policy.
So a widget losing focus might mean that my cat has moved the mouse or
it might mean I've gone to another application to look for information,
perhaps to copy some text to paste into the widget. It might mean the
system has popped up a completely unrelated alert that has grabbed the
focus.

It seems a no-brainer that loss of focus should do *nothing* to the edit
state, nor should a subsequent regaining of focus. Explicit keyboard or
mouse actions on the widget itself should be used to change state, or
method invocations by associated widgets because of user actions on
them. That's fundamental for a sane user experience, I believe.

Yes, there are programming issues associated with abandoning a widget in
an editing-in-progress state but they just need careful coding.

JMHO, Dave