Re: Editable GtkCellRendererText and focus

[Yevgen Muntyan <muntyan tamu edu>]

Tim Evans wrote:
> In our application, I have run into a problem with the behaviour of 
> GtkCellRendererText when an cell being edited loses focus.  The 
> problem appears to be caused by the fix to Bug #164494:
>
>   bug: http://bugzilla.gnome.org/show_bug.cgi?id=164494
>   patch: 
> http://svn.gnome.org/viewcvs/gtk%2B/trunk/gtk/gtkcellrenderertext.c?r1=16769&r2=16809 
>
>
> I've attached a small PyGTK script that illustrates the problem.  Our 
> users are presented with a GtkTreeView containing a list of strings to 
> edit.  Having changed the values to their satisfaction, they click 
> "OK". The problem is that the last change they make is not applied: no 
> 'edited' signal is emitted on the GtkCellRendererText, so my code does 
> not modify the underlying model.
>
> Clicking the "OK" button (or using the Alt+O mnemonic) removes focus 
> from the GtkEntry that is editing the cell and places it on the OK 
> button, standard behaviour for buttons.  The problem is that when the 
> focus is removed from the GtkEntry editing is cancelled rather than 
> confirmed.  If the user press enter (even tab or the up or down arrow) 
> then the change is correctly applied.  But they feel no need to press 
> enter, the value looks correct and they don't see the significance of 
> it being a GtkEntry in an editable cell rather than a normal tree-view 
> display.  The text is as they want it and by pressing "OK" they mean 
> to confirm their changes.
>
> I can't help but feel that this is a bug in GTK, and that the patch 
> linked above is incorrect at least in my case.  Does anyone else feel 
> the same, or am I doing something wrong on my end?
I totally agree that it's a bug. Imagine this: you edit
an entry in a list and you click elsewhere. Now, if you
clicked the treeview itself, you get changes committed.
If you click other widget, you get changes lost. This
case with OK button is especially bad, since user has
no clue his change is lost.
Note that it's simply a breakage in new gtk since
in gtk-2.8 editing and switching focus to something
else works fine.

What's wrong with the filechooser, by the way? File
managers seem to work that way: you say "Create
Folder" and it creates folder. If you're unhappy, you
delete it. If you changed your mind while editing
name, hit Escape which means "Cancel", i.e. "No don't
create it". How is *switching focus* an indicator of
whether you want or do not want a folder on disk
to be created?

Best regards,
Yevgen