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 423201 - gtk_combo_box_entry_active_changed does not transform values
gtk_combo_box_entry_active_changed does not transform values
Status: RESOLVED FIXED
Product: gtk+
Classification: Platform
Component: Widget: GtkComboBox
2.10.x
Other Linux
: Normal normal
: ---
Assigned To: gtk-bugs
gtk-bugs
Small Patch
Depends on:
Blocks:
 
 
Reported: 2007-03-27 04:45 UTC by muppet
Modified: 2010-10-15 21:01 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Simple test case (1.42 KB, text/plain)
2007-03-27 04:51 UTC, muppet
  Details
Patch to coerce values to strings (1.09 KB, patch)
2007-03-27 04:53 UTC, muppet
none Details | Review
Updated Muppet's patch (1.14 KB, patch)
2008-04-27 03:39 UTC, Björn Lindqvist
none Details | Review
Use property system to coerce model data to G_TYPE_STRING (1.52 KB, patch)
2010-10-15 14:31 UTC, Christian Dywan
accepted-commit_now Details | Review

Description muppet 2007-03-27 04:45:50 UTC
If you create a GtkComboBoxEntry with a text column that is not a G_TYPE_STRING, the application SEGVs when the active iter changes.

There is no warning about the incompatible column type, and no checking of the type.  In gtk_combo_box_entry_active_changed(), the code simply assumes that it got a string back from the model, and passes that directly to the Entry.

This violates the Principle of Least Surprise.  You can use a GtkCellRendererText to display a column of nearly any type, and the value will be coerced into a string by GValue's transformations.  A developer may reasonably expect that GtkComboBoxEntry would do the same, especially since there is no warning or critical assertion about the type mismatch.

A trivial patch to gtkcomboboxentry.c fixes this.

The question is, am i right in thinking that the combobox should do this coercion?  Or should the user simply use a G_TYPE_STRING column for the ComboBoxEntry's "text-column"?


The bug is marked as affecting 2.10, but i have verified that it affects both FC2's 2.4.x and trunk@HEAD.
Comment 1 muppet 2007-03-27 04:51:45 UTC
Created attachment 85364 [details]
Simple test case

This is a very simple test case that demonstrates the bug.  Simply select something from the dropdown, and you get a SIGSEGV in strcmp() from gtk_combo_box_entry_active_changed().
Comment 2 muppet 2007-03-27 04:53:27 UTC
Created attachment 85365 [details] [review]
Patch to coerce values to strings

Straightforward patch to use the object property system to trigger GValue transformation of the model's value, instead of assuming that it is a G_TYPE_STRING.  Patterned after similar code in gtktreeviewcolumn.c.
Comment 3 makuchaku (Mayank) 2007-03-27 14:31:00 UTC
Muppet, please add the changelog.

Thanks :)
Comment 4 muppet 2007-03-27 14:45:49 UTC
Like this?  Or do you want that in the patch, as well?


2007-03-27  muppet <scott@asofyet.org>

	* gtk/gtkcomboboxentry.c: (gtk_combo_box_entry_active_changed):
	Use property system to coerce model data to G_TYPE_STRING. Bug #423201.
Comment 5 Emmanuele Bassi (:ebassi) 2007-03-27 21:10:31 UTC
avoiding a segmentation fault should be a reason enough to apply this patch; either this or a g_critical() is added and the fact that no coercion is done should be written in the documentation.
Comment 6 Björn Lindqvist 2008-04-27 03:39:40 UTC
Created attachment 109970 [details] [review]
Updated Muppet's patch

Updated Muppet's patch to head. It still works as advertised. No crashes and non-string columns are coerced.
Comment 7 Murray Cumming 2010-10-02 12:30:30 UTC
Is there any reason why this can't be committed?
Comment 8 Christian Dywan 2010-10-15 14:31:20 UTC
Created attachment 172426 [details] [review]
Use property system to coerce model data to G_TYPE_STRING

Updated patch against master.
Comment 9 Matthias Clasen 2010-10-15 17:23:08 UTC
Review of attachment 172426 [details] [review]:

Looks fine to me.