GNOME Bugzilla – Bug 655500
GtkEntry: Shall language bindings wrap the activate signal?
Last modified: 2012-06-12 14:13:33 UTC
Overview: Not sure if this bug belongs to component GtkComboBox or component GtkEntry (probably both). When the user types text in a GtkEntry widget (within a GtkComboBox or elsewhere), the "changed" signal is emitted once for each typed character. But if you want to know when the user presses the enter key, thus showing that he or she has finished typing, which signal shall you connect to? Both GtkComboBox and GtkEntry have an "editing-done" signal, inherited from GtkCellEditable. The documentation at http://developer.gnome.org/gtk3/unstable/GtkCellEditable.html#GtkCellEditable-editing-done says: Implementations of GtkCellEditable are responsible for emitting this signal when they are done editing, e.g. GtkEntry is emitting it when the user presses Enter. That's not true. I've modified the example program tests/testcombo, and connected to some signals. "editing-done" is never emitted. GtkEntry's "activate" signal is emitted, when the enter key is pressed. The "activate" signal is a bit dubious. It's wrapped in gtkmm. A comment in gtkmm's entry.hg file refers to http://mail.gnome.org/archives/gtk-devel-list/2003-January/msg00108.html, saying Murray Cumming: > So I'd like to know what signals are "keybinding" signals. I thought I > could just check for uses of gtk_binding_entry_add_signal(), but that's > used on GtkEntry's "activate" signal, and I'm told that that's not a > keybinding signal. Owen Taylor: activate is probably about the only exception in that direction The gtk+ documentation of GtkEntry's "activate" signal at http://developer.gnome.org/gtk3/unstable/GtkEntry.html#GtkEntry-activate says: A keybinding signal which gets emitted when the user activates the entry. Applications should not connect to it, but may emit it with g_signal_emit_by_name() if they need to control activation programmatically. The default bindings for this signal are all forms of the Enter key. Steps to reproduce: I will attach a modified version of test program tests/testcombo to this bug. Run it, and check what signals are emitted, when you make changes in "GtkComboBox with entry". Actual results: Both "changed" signals are emitted every time the entry field is changed, either by typing in it, or by selecting an item in the drop-down list. None of the "editing-done" signals are ever emitted. The "activate" signal is emitted when enter is pressed. Expected results: Not sure. Either the documentation of GtkCellEditable's "editing-done" signal is wrong, or GtkEntry does not react correctly when the enter key is pressed. Anyway, we need a signal that applications can use for detecting a pressed enter key in a GtkEntry widget. "activate" can be used, but the documentation says "don't do it!" "editing-done" is never emitted (or at least it seems so when I test it), but the documentation says it can be used. Build date and platform: Ubuntu 11.04, source code of gtk+, etc. from git's master branch, built with jhbuild on 2011-07-24. Additional information:
Created attachment 192814 [details] Modified version of tests/testcombo.
Is this part of an explanation for the missing "editing-done" signals? Neither gtk_combo_box_start_editing() nor gtk_entry_start_editing() is called, because gtk_cell_editable_start_editing() is not called. I've checked with gdb that none of these 3 functions is called. gtk_entry_start_editing() contains g_signal_connect (cell_editable, "activate", G_CALLBACK (gtk_cell_editable_entry_activated), NULL); and gtk_cell_editable_entry_activated() in gtkentry.c emits an "editing-done" signal. The remaining question is then: When and from where shall gtk_cell_editable_start_editing() be called? The only call to it that I've found in gtk+ code is from gtk_cell_area_activate_cell().
I suspect that this is fixed by the commit in bug #653289 .
No, there's no difference. Neither GtkComboBox nor GtkEntry emits the "editing-done" signal. And applications are still not allowed to connect to the "activate" signal, emitted by GtkEntry. The problem description in bug 653289 says: 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. The problem with "editing-done" in GtkComboBox and GtkEntry is that it's _never_ emitted, not even when return is pressed. I would not mind if "editing-done" is emitted also when the GtkEntry loses keyboard focus, but that's less of a problem, because it can be detected by connecting to the "focus-out-event" signal, inherited from GtkWidget.
Have you tried if this works with a regular GtkEntry, without a GtkComboBox? Is this a problem only with GTK+ 3 or also with GTK+ 2?
Created attachment 198707 [details] Test case with: 1. GtkComboBox with has-entry, 2. GtkEntry The GtkComboBox with has-entry is the same as in comment 1. I have removed everything else from that test case, and added a GtkEntry. The "editing-done" signal is still not emitted, neither from GtkComboBox nor from GtkEntry, neither in gtk+2 nor in gtk+3.
(In reply to comment #6) > The "editing-done" signal is still not emitted, neither from GtkComboBox nor > from GtkEntry, neither in gtk+2 nor in gtk+3. Thanks, so surely the test case should just show GtkEntry and not confuse things by involving GtkComboBox too?
Both GtkComboBox and GtkEntry implement the GtkCellEditable interface, where the editing-done signal is created. I suppose that ideally both GtkComboBox and GtkEntry should emit that signal, when a GtkEntry is the child of a GtkComboBox. I don't see any harm in having both a GtkComboBox with GtkEntry, and a separate GtkEntry in the test case. But the emission of editing-done from GtkEntry is more important than the emission from GtkComboBox. I change this bug's component from GtkComboBox to GtkEntry.
Created attachment 198777 [details] Small test case with only a GtkEntry. I wonder if we have zoomed in too much on the editing-done signal. I would like to return to the original question in this bug report, reformulated: How can an application, in an acceptable way, detect when the user presses return in a GtkEntry widget with the activates-default property = FALSE? I can imagine two alternative answers, and both of them require changes in gtk+. 1. Connect to the "editing-done" signal. This is what the documentation says, but it doesn't work. http://developer.gnome.org/gtk3/unstable/GtkCellEditable.html#GtkCellEditable-editing-done 2. Connect to the "activate" signal. This works, but the documentation says it's not acceptable. http://developer.gnome.org/gtk3/unstable/GtkEntry.html#GtkEntry-activate GtkStatusIcon allows applications to connect to its "activate" signal. http://developer.gnome.org/gtk3/unstable/GtkStatusIcon.html#GtkStatusIcon-activate
Created attachment 201597 [details] Modified test case with only a GtkEntry. Compared to the test case in comment 9, I have added signal handlers for focus-out-event and key-press-event. Have I misunderstood the purpose of the editing-done signal? When GtkEntry or GtkComboBox is used by a cell renderer in a GtkTreeView, gtk_cell_area_activate_cell() calls gtk_cell_editable_start_editing(), and thus gtk_entry_start_editing() or gtk_combo_box_start_editing() is called. Then the editing-done signal is emitted when Enter is pressed, as expected. gtk_entry_start_editing() and gtk_combo_box_start_editing() set the private flag is_cell_renderer = TRUE, which makes me convinced that these functions shall be called only when the GtkEntry or the GtkComboBox is used by a cell renderer. (I have tested with gdb on the C++ example programs http://git.gnome.org/browse/gtkmm-documentation/tree/examples/book/treeview/combo_renderer and .../treeview/editable_cells.) Summary: When GtkEntry or GtkComboBox is used by a cell renderer, and Enter is pressed, the editing-done signal is emitted. When GtkEntry or GtkComboBox is used in other situations, the editing-done signal is not emitted. And that's by design, isn't it? The only acceptable way for an application to detect a pressed Enter key would then be to connect to the key-press-event signal, as demonstrated by the test case in this comment. Is that correct?
editing-done is part of the GtkCellEditable interface and as such is only relevant when the entry or combo box are used as the editing widget for a cell renderer. If connecting to ::activate works for you depends a bit on what you want. It gets activated by keybindings, which can be changed, although it is probably unlikely that it would be changed to something other than variations of Enter. It can also be emitted programmatically, by gtk_widget_activate(). If you are really after the Enter key, then filtering on key-press-event is a better way to go.
(In reply to comment #11) > If connecting to ::activate works for you depends a bit on what you want. > It gets activated by keybindings, which can be changed, although it is probably > unlikely that it would be changed to something other than variations of Enter. > It can also be emitted programmatically, by gtk_widget_activate(). We wrap this in gtkmm as real API because Owen said that it should be used: http://mail.gnome.org/archives/gtk-devel-list/2003-January/msg00108.html
Is this a correct summary concerning GtkEntry's activate signal? - Owen Taylor's post on gtk-devel-list in January 2003 is obsolete. http://mail.gnome.org/archives/gtk-devel-list/2003-January/msg00108.html - Matthias Clasen's documentation from December 2008 is valid now and in the foreseeable future. http://developer.gnome.org/gtk3/unstable/GtkEntry.html#GtkEntry-activate - Gtkmm should deprecate its wrapping of GtkEntry's activate signal, and remove it at the next API break. http://developer.gnome.org/gtkmm/unstable/classGtk_1_1Entry.html#a8ca968ac536264b82d7f603d5c985c4d
Gtkmm's wrapping of GtkEntry's activate signal has been deprecated. See bug 655489 comment 10. Closing this bug.
Matthias Clasen seems to have decided about GtkEntry:activate and added an explicit comment about this, saying that we _should_ use it: http://git.gnome.org/browse/gtk+/commit/?id=4a25bac0e7685000fff90a211db6ac60f6b74ab1 So I have removed the deprecation from Gtk::Entry::signal_activate: http://git.gnome.org/browse/gtkmm/commit/?id=d2aeb005f1c52a328009f7ed095e8a913f6d9cb1 I wonder if we need to change any of our gtmm documentation or examples back again.
(In reply to comment #15) > I wonder if we need to change any of our gtmm documentation or examples back > again. Yes, we need to partly undo the changes. But only partly, because some still useful info was added. Let's use the gtkmm bug 655489 for that.