After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 317387 - CellRendererCombo's "edited" signal not firing when needed
CellRendererCombo's "edited" signal not firing when needed
Product: gtk+
Classification: Platform
Component: Widget: GtkTreeView
Other Linux
: Normal normal
: ---
Assigned To: gtktreeview-bugs
: 326892 (view as bug list)
Depends on:
Reported: 2005-09-27 23:49 UTC by Daniel Kasak
Modified: 2018-02-10 03:33 UTC
See Also:
GNOME target: ---
GNOME version: ---

Script that demonstrates issue with CellRendererCombo (4.30 KB, text/plain)
2005-09-27 23:50 UTC, Daniel Kasak
Bug test script in python (1.75 KB, application/x-python)
2006-01-17 15:25 UTC, _v_tiziano

Description Daniel Kasak 2005-09-27 23:49:00 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

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.
Comment 1 Daniel Kasak 2005-09-27 23:50:43 UTC
Created attachment 52755 [details]
Script that demonstrates issue with CellRendererCombo
Comment 2 Daniel Kasak 2005-09-28 00:12:29 UTC
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.
Comment 3 _v_tiziano 2006-01-17 15:25:31 UTC
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.
Comment 4 Daniel Kasak 2006-04-13 02:22:21 UTC
Comment 5 Daniel Kasak 2006-06-30 06:41:41 UTC
Dataloss bug?
Confirmed by other users?
2 different scripts that demonstrate the problem?
Pretty please?
Comment 6 Daniel Kasak 2006-08-15 03:47:32 UTC
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;

   editable        => TRUE,
   text_column     => 1,
   has_entry       => FALSE #

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.
Comment 7 Kristian Rietveld 2007-01-03 00:09:22 UTC
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.
Comment 8 Kristian Rietveld 2007-01-03 00:10:42 UTC
*** Bug 326892 has been marked as a duplicate of this bug. ***
Comment 9 Kristian Rietveld 2007-06-06 09:57:21 UTC
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.
Comment 10 Erlend Davidson 2007-08-28 09:51:53 UTC
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

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:
Comment 11 Matthias Clasen 2018-02-10 03:33:55 UTC
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.