GNOME Bugzilla – Bug 653289
GtkCellRendererText "edited" signal not emitted when clicking out of cell.
Last modified: 2013-10-01 08:22:21 UTC
With GTK+ 3 (at least with git master), GtkCellRendererText's "edited" signal is not emitted when I click into the next cell in the treeview. It is apparently only emitted when I press return. This is not a problem with GTK+ 2.24.
Bug #643328 might be related.
You can see this, for instance, in GtkFileChooserDialog when creating a new folder. Your new name for the folder will be lost if you click away instead of typing Enter. It also happens in Nautilus when renaming files.
Most likely something to talk to Tristan about, fallout from the cell area refactoring ?
(In reply to comment #3) > Most likely something to talk to Tristan about, fallout from the cell area > refactoring ? Yes, on a first thought that is pretty likely. Otherwise I hope to get to it once I've finished the other stuff I have on my plate ...
Created attachment 195297 [details] [review] Lets "edited" signal be emitted when focusing out from GtkCellRendererText. I'm attaching a patch maybe fixing this bug. This makes a code sent to gtk-devel-list[1] behaving as expected. [1] https://mail.gnome.org/archives/gtk-devel-list/2011-August/msg00048.html
Created attachment 195375 [details] Tarball with test.c and Makefile I'm attaching a test app in C compilable against gtk2 and gtk3 based on vala code from the link in message above. Typing 'make all' produces binaries for gtk2 and gtk3 called gtk-test-2 and gtk-test-3 respectively. Some signals were connected in a way that their names appear on title bar for 5 seconds.
Created attachment 195377 [details] [review] Lets "edited" signal be emitted when focusing out from GtkCellRendererText. Apparently the commit description in previous patch was wrong. Attached updated one.
Does anyone know why that small change is necessary now? Could it really be related to the refactoring?
The problem sounds related to the refactor, the GtkCellArea is now responsible for managing a 'focus cell' and has some focus navigational apis. I'm afraid the fix looks a bit disturbing though, theres no explanation why that line should have to change from GTK+2 to GTK+3. If I understand correctly (and there are many use cases, I might have this wrong off hand), the desired behavior I believe is: - Click in another cell means "edited" - Tab away from the cell (or press escape) means "canceled" I wonder if the proposed patch causes the former to succeed but the latter to fail. It could be that the order of event callbacks has changed, erroneously giving the last say to the GtkEntry focus-out callback (I'm quite sure the click on another cell in the treeview is delivered before the focus-out event is sent to the entry) I'm really not sure whats going on though. It could be that something is still missing in the GtkCellArea apis to account for this, or that some detail in the cell area focus implementation is wrong.
(In reply to comment #9) > I'm really not sure whats going on though. It could be that something is still > missing in the GtkCellArea apis to account for this, or that some detail in the > cell area focus implementation is wrong. I think it's possible some detail that is wrong, because there is another bug that I think it related (but I haven't been able to look at it in detail yet). I can't find that other bug so quickly at the moment ...
(In reply to comment #9) > The problem sounds related to the refactor, the GtkCellArea is now responsible > for managing a 'focus cell' and has some focus navigational apis. > > I'm afraid the fix looks a bit disturbing though, theres no explanation why > that > line should have to change from GTK+2 to GTK+3. > > If I understand correctly (and there are many use cases, I might have this > wrong off hand), the desired behavior I believe is: > - Click in another cell means "edited" > - Tab away from the cell (or press escape) means "canceled" Testing the gtk2 application gives: - "edited" signal emitted when pressed ENTER, clicked on other cell or tabbed from the cell. - "editing-canceled" when pressed ESC or alt-tabbed to other app. Testing the "gtk3 HEAD without my patch applied" application gives: - "edited" signal emitted when pressed ENTER. - "edited" signal _not_ emitted when clicked on other cell or tabbed from the cell - "editing-canceled" when pressed ESC or alt-tabbed to other app. Testing the "gtk3 HEAD with my patch applied" application gives: - "edited" signal emitted when pressed ENTER, clicked on other cell, tabbed from the cell or alt-tabbed to other app. - "editing-canceled" when pressed ESC. So clearly my patch is wrong. (In reply to comment #10) > I think it's possible some detail that is wrong, because there is another bug > that I think it related (but I haven't been able to look at it in detail yet). > I can't find that other bug so quickly at the moment ... The one in comment 2?
Created attachment 198167 [details] [review] Patch to make gtk_cell_area_stop_editing() call gtk_cell_editable_editing_done() I was able to get to the bottom of this by simply putting a breakpoint on gtk_cell_renderer_text_editing_done() (which is responsible for emitting the "edited" signal) in both GTK+2 and GTK+3 compilations of the test. Much thanks for providing a great test case for this. Simply, the GtkCellArea is not calling gtk_cell_editable_editing_done() in gtk_cell_area_stop_editing() as it should do. If you observe the gtk-2-24 branch you can note that gtk_tree_view_stop_editing() was previously responsible for making this notification (now in GTK+3, gtk_tree_view_stop_editing() simply delegates the dirty cell/edit widget work to gtk_cell_area_stop_editing()).
Comment on attachment 198167 [details] [review] Patch to make gtk_cell_area_stop_editing() call gtk_cell_editable_editing_done() Makes sense.
Pushed to master and gtk-3-2 branch (gave testtreeedit and testiconview a spin first).
Excellent. Thanks. This fixes the issue for me in Glom.
I have a similar problem when in a dialog window I edit a cell_area and then I press a button to close the dialog window. The "edited" signal is not emitted. Should it be?
My problem is solved if I use the patch by Krzesimir Nowak https://bugzilla.gnome.org/attachment.cgi?id=195297&action=diff, that I see it is now obsolete. Can it be pushed?
Anna, I think that's a separate issue. I think it's been that way for a long time. I don't like it either, but it's not a regression.