GNOME Bugzilla – Bug 378040
should use -GMAXFLOAT instead of G_MINFLOAT in Value<float>::create_param_spec()
Last modified: 2006-11-22 11:14:57 UTC
Please describe the problem: We are currently trying to integrate gtkmm-widgets (Gtk::Widget - derived classes) into glade3's palette and had some success with it, even Glib::Property-Members of the class show up in glade's "Properties" window. However, you cannot have 0 or smaller as a default value for Glib::Property<float> ot Glib::Property<double>, glade complains about the value being smaller than the default and refuses to show the property. Digging int it, i found that GParamSpec* Value<float>::create_param_spec(const Glib::ustring& name) in glib/glibmm/value_basictypes.cc defines G_MINFLOAT as the minimum value for the created param_spec. G_MINFLOAT, however, is defined as the smallest possible float and e.g on x86 is something like 1.175494e-38. The same applies to Value<double>::create_param_spec, respectively. so, if create_param_spec intends to make available the whole range of values (as do the int types) we should possibly use -G_MAX_FLOAT. I've tested this on x86, and -GMAX_FLOAT seems to be a valid float value, but I'm not so sure about other architectures, so perhaps someone with more insight into internal float representation could shed some light on it. Steps to reproduce: Actual results: Expected results: Does this happen every time? Other information:
Created attachment 77016 [details] [review] possible patch
Yes, this seems to be a common error, and one that the documentation has been updated to help with: http://developer.gnome.org/doc/API/2.0/glib/glib-Limits-of-Basic-Types.html#G-MINFLOAT:CAPS http://mail.gnome.org/archives/gtk-devel-list/2001-June/msg00308.html Well done. Feel free to commit (with a ChangeLog entry) if you have access.
(In reply to comment #2) > Well done. Feel free to commit (with a ChangeLog entry) if you have access. No access (yet), sorry. Would you like to commit it?
Committed to the HEAD, glibmm-2-12, and glibmm-2-10 branches. Thanks.