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 378040 - should use -GMAXFLOAT instead of G_MINFLOAT in Value<float>::create_param_spec()
should use -GMAXFLOAT instead of G_MINFLOAT in Value<float>::create_param_spec()
Status: RESOLVED FIXED
Product: glibmm
Classification: Bindings
Component: object
2.12.x
Other All
: Normal normal
: ---
Assigned To: gtkmm-forge
gtkmm-forge
Depends on:
Blocks:
 
 
Reported: 2006-11-22 08:24 UTC by Oliver Nittka
Modified: 2006-11-22 11:14 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
possible patch (744 bytes, patch)
2006-11-22 08:26 UTC, Oliver Nittka
none Details | Review

Description Oliver Nittka 2006-11-22 08:24:17 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:
Comment 1 Oliver Nittka 2006-11-22 08:26:11 UTC
Created attachment 77016 [details] [review]
possible patch
Comment 2 Murray Cumming 2006-11-22 09:06:06 UTC
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.
Comment 3 Oliver Nittka 2006-11-22 09:27:40 UTC
(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?
Comment 4 Murray Cumming 2006-11-22 11:14:57 UTC
Committed to the HEAD, glibmm-2-12, and glibmm-2-10 branches. Thanks.