GNOME Bugzilla – Bug 317387
CellRendererCombo's "edited" signal not firing when needed
Last modified: 2018-02-10 03:33:55 UTC
Distribution/Version: Gentoo I am attaching a small gtk2-perl script that demonstrates the issue. You will need gtk2-perl 1.08x or greater, compiled against gtk-2.6 or greater. Run the script from a terminal. Enter data in the first column, and *immediately* after entering something ( ie before hitting enter to finish editing the cell ), click the 'dump values' button. Note that the cell's "edited" signal fires, is handled correctly by my process_editing sub, and is picked up by the dump_values sub. The same also works for the 2nd cell, which is basically exactly the same as the 1st. Now try using the mouse to select an item from the 3rd column's CellRendererCombo. *Immediately* after selecting an item, click the 'dump values' button. Note how the CellRendererCombo's "edited" signal never fires, and therefore my process_editing sub is never called, and the dump_values sub doesn't see the changes ... even though the changes are visible on-screen.
Created attachment 52755 [details] Script that demonstrates issue with CellRendererCombo
I just tested with gtk-2.8.3 and can reproduce the problem with this release as well. Should I increase the bug's version number to reflect this? I'm leaving it as-is for now.
Created attachment 57537 [details] Bug test script in python This problem affect gtk-2.8.6 and pygtk-2.8.1 to. In the test script attached the callback function of the 'edited' signal reproduce a 'beep'. This work for the 1st column, but fails on 2nd.
.
Dataloss bug? Confirmed by other users? 2 different scripts that demonstrate the problem? Pretty please?
I have found a 'workaround' of sorts. If I set the 'has_entry' property to FALSE ( ie if I disable the Entry renderer ), then this bug disappears. eg: my $combo = Gtk2::CellRendererCombo->new; $renderer->set( editable => TRUE, text_column => 1, has_entry => FALSE # http://bugzilla.gnome.org/show_bug.cgi?id=317387 ); This appears to work around other issues with the Combo renderer as well, eg typing in a value that is in the model didn't return a match. This problem also disappears because the user now can't type anything, as there is no Entry to type into.
In my opinion it makes sense that a combo box with an entry does not immediately stop editing after selecting a value in the list because it is perfectly valid to choose a value, edit it and then accept it. I am not sure if it makes sense to stop editing after selecting a value in the list in that case, since for the scenario described above you would have to: - Start editing; - select a value from the list, the editing will automatically stop; - start editing again; - modify the value and press enter to accept. The right solution is probably to fire "edited" twice; once after selecting a value from the list and once after accepting the input. It seems to be fine to emit edited before editing-done has been emitted -- though getting signaled only when a value is picked from the list is a little tricky, by default GtkComboBoxEntry also emits changed for each change in the entry (which does make sense). Events we need to monitor are probably changes by picking an item from the list with a mouse and by up/down arrow keys in the entry (if has-entry is TRUE). Another thing which needs fixing to match the behavior of GtkCellRendererText is that the combo renderer has to cancel editing when the tree view loses focus. From a quick look it seems that we need to listen for focus-out-event on the entry of the combo box and not on the combo box itself. Also when clicking outside of the popup menu it should popdown (as it does now) *and* cancel the editing operation. Note that cancelling the editing operation *after* an item has been picked from the list will then only discard the changes made to the entry *after* picking the item from the list. I think that picking an item from the list should be seen as an "accepted change", thus edited will be emitted for that -- changes in an entry are not accepted until enter or ctrl+arrow has been pressed. I will be working on a patch tweaking the behavior.
*** Bug 326892 has been marked as a duplicate of this bug. ***
Instead of firing edited when an item is selected in the list, we are thinking about adding a changed signal to GtkCellRendererCombo: #324282. The focus-out issues will he handled in this report.
I get this problem too with python and gtk (pygtk). I use the following callback to handle the cell edit: # handles the editing of a treeview cell def edited_cb(self, cell, path, new_text, user_data): print "Change '%s' to '%s'" % (user_data[path][1], new_text) user_data[path][1] = new_text return However, this doesn't work when the treeview loses focus without the user pressing enter. I certainly believe this is a problem as there appears to be no way around it, i.e. if the programmer wants to catch 'focus-out-event' it won't help since he doesn't have 'path'. The bug is also discussed here: http://www.nabble.com/Editable-GtkCellRendererText-and-focus-t3899672.html
We're moving to gitlab! As part of this move, we are closing bugs that haven't seen activity in more than 5 years. If this issue is still imporant to you and still relevant with GTK+ 3.22 or master, please consider creating a gitlab issue for it.