GNOME Bugzilla – Bug 107633
gimp_coordinate does not emit value-changed signal
Last modified: 2004-12-22 21:47:04 UTC
When both coordinates are "chained" the gimp_coordinate widget does not emit a "value-changed" signal, even though this signal is emitted when the coordinates are not "chained". This is apparently caused by the call to g_signal_stop_emission_by_name in the function gimp_coordinates_callback. The purpose of this call is not clear. When there is another signal that is emitted on a change (I could not find one) this should be documented.
gimp_coordinates_new() is just a convenience function to create a GimpSizeEntry and it is documented as such. You usually don't connect to the "value-changed" signal of a GimpSizeEntry since the whole point is to hide the ugly details of value changes. If you use a GimpSizeEntry you are interested in changes of the reference value and thus use the "refval-changed" signal as documented here: http://developer.gimp.org/api/1.3/libgimpwidgets/GimpSizeEntry.html However you are probably right that we should emit a value-changed signal from the gimp_coordinates_callback() even if it is solely for correctness.
The "refval-changed" signal does not seem to work in my code. It is only emitted in gimp_size_entry_refval_callback, that is a signal handler for the "value-changed" signals from the underlying adjustments. This signal handler is never connected when show_refval is FALSE. gimp_coordinates_new creates new GimpSizeEntry's with show_refval set to FALSE. I may have overlooked something, but it appears that gimp coordinates will never emit a "refvalue-changed" signal.
Changes at the request of Dave Neary on the developer mailing list. I am changing many of the bugzilla reports that have not specified a target milestone to Future milestone. Hope that is acceptable.
Changing milestone on a bunch of bugs to 2.0 - none of these could be considered a blocker for a pre-release, IMHO. Many of these have patches or someone working on them, but they're not urgent. Dave.
I have investigated this a bit and it doesn't seem that neither the "refval-changed" or the "value-changed" signal is emitted when the chaining is active. When the chaining is inactive the signal "value-changed" is emitted correctly, but "refval-changed" will never be emitted since gimp_coordinates_new() calls gimp_size_entry_new() with show_refval=FALSE. The "unit-changed" signal is emitted correctly. The "value-changed" signal is blocked by the call to g_signal_stop_emission_by_name() in gimp_coordinates_callback(). Removing the call to g_signal_stop_emission_by_name() would allow connecting to the "value-changed" signal - and since none of the plug-ins using gimp_coordinates_new() connects to the signals - won't break anything. Perhaps yosh can tell us why the call to g_signal_stop_emission_by_name() was added?
Fixed in CVS. 2003-08-16 Michael Natterer <mitch@gimp.org> * libgimpwidgets/gimpwidgets.c (gimp_coordinates_callback): moved the g_signal_stop_emission_by_name() right before the calls to gimp_size_entrs_set_refval() so we only block the duplicate "value_changed" signal, not all of them. Fixes bug #107633.