Rather than the previously reverted commit, the proper solution is:
* gimp_color_selector_set_color() must not test for perceptual identity
because GimpColorSelector is too much of a generic class. In some
case, such a test may be worth it to limit costly updates (in
particular when it implies some rendering of color surfaces), but this
would happen in specific subclasses.
* In GimpColorSelection, the GimpColorScales show numbers, so any change
in them will likely trigger other scales to change as a side effect.
Therefore when handling the "color-changed" signal on these scales,
however small the change may be, we want to run the update.
Now removing this test in gimp_color_selector_set_color() also revealed
a serious bug which I fix in this commit, which is that the binding
between the "value" of a GimpLabelSpin with the "value" of its
adjustment was still triggering repeated property-setting, which was
enough to freeze the GUI for a while. The logic of using only the
GtkAdjustment's value as a source while also binding both properties was
not robust enough. Instead the GimpLabelSpin will now store its own
value and the binding will simply keep it in sync with the one in the
adjustment.
Note that this is also part of the solution for #10998, because it means
there were cases where the color displayed in scales of the color
selection dialog was not actually the color set as foreground or
background.
For certain min/max values of the LabelSpin widget, in combination with
zero digits, it proves impossible to change the initial value.
The reason for this is that the step size may become less than 1.0.
In which case, stepping doesn't work because the number of digits is
set to zero.
Let's check for this situation and when digits is zero set the step
to 1.0 and make sure that page is at least the same value.
While testing this I also noticed another issue: when initializing
the upper value was set to 0.0 and the lower to 1.0 which leads to
a critical because lower > upper.
We fix this by switching the initial upper and lower values.
The assert tests were not taking well into account the case where upper == lower
or where it's an integer spin which is just separated by 1 (both cases seem
silly, but it makes sense in the case of generic — or even dynamic! — spin
widgets where we want to adjust the min and max, e.g. depending on the property
of the image, or on other settings.
… gimp_label_spin_set_digits() and deleted gimp_prop_opacity_entry_new()
- The "digits" argument for the number of decimal places in
gimp_prop_scale_entry_new() is now mostly useless since GimpLabelSpin
(hence GimpScaleEntry too) got a nice estimation algorithm of sensible
values.
- Add gimp_label_spin_set_digits() function to manually set the digits
property when we don't like the estimated value.
- Also add a new "factor" argument to gimp_prop_scale_entry_new(). Its
role is to allow a GimpScaleEntry showing a factored range, typically
a [0, 100] range for some types of [0, 1] properties.
- Remove gimp_prop_opacity_entry_new() which was basically a
special-case of gimp_prop_scale_entry_new() and which can now be
easily reproduced by simply set factor=100.0.
- Update all usage of gimp_prop_scale_entry_new() in app/ and plug-ins/
with updated arguments. It is interesting to note that all existing
usage were either integers (digits=1) or when double, the estimated
decimal places are the same as the ones which were manually set (hence
showing the generic estimation is not too bad). So the new function
gimp_label_spin_set_digits() was not even needed once in current code.
Similar code was used in 2 places basically (GimpLabelSpin and
GimpProcedureDialog) so just make it an utils function. It's good anyway
to have a generic function to estimate suitable increments and decimal
places depending on a range.
As a consequence also gimp_label_spin_new() now takes a gint digits
(instead of guint), with -1 meaning we want digits computed from the
range.
Similarly gimp_prop_scale_entry_new() docs adds the -1 meaning too.
There is currently no property widget which just creates a
GimpSpinButton with a label. Just as the GimpScaleEntry was needed, this
one is as well.
I am creating a GimpLabeled abstract class which will represent various
widgets with a label. While this may seem a bit over-engineered for such
a basic feature, this will actually bring some consistency and a common
parent. In particular this can be used to get the GtkLabel with a common
interface to add them all in a common GtkSizeGroup when generating
dialogs automatically, hence make dialogs with properly aligned labels
and edition widgets.
