Similar to 42300d9d, we want to prevent overly long color profile
labels from stretching out dialogues with GimpColorSelect too far.
This patch adds gtk_label_set_ellipsize () to both the color profile
and simulation profile labels, and adds them to a grid instead of
letting them free-flow.
...with gtk_icon_theme_add_resource_path (). Per Wormnest in !1027, this function
might not even be necessary at all. But until removing it can be completely tested,
this patch at least removes the deprecation warning for GIMP 3.0 RC1.
The whole widget was made deprecated in 2006 (commit 99f979e118) but it
is still being used by another widget. Since we can break API, I at
least hide the functions and type by making these private.
This will give us time to think if we really need this widget (or a
nicer implementation for this widget) or if we just want to get rid of
it.
Checking the log, it looks like this code has not been touched since
2007, so whatever this various was used for, it's clearly not been used
for a long time.
Fixes warning:
> libgimpwidgets/gimpcairo-utils.c:80:16: warning: variable 'total_length' set but not used [-Wunused-but-set-variable]
Always update stored colors. When colors are perceptually identical, we
only bypass color rendering code, but not the color value update (even
small value updates need to be echoed across the code, so that what is
shown is always what is set).
Commit abf0c1c272 fixed the inconsistency of showing "R" for RGB's Red
channel selected whereas the actually displayed selection UI was "H" for
HSV's Hue channel.
As a consequence of this fix, now we were indeed displayed "R". Yet
people got used to working with the Hue channel (and LC plane) for
at least a dozen years. Let's make "H" the officially displayed channel.
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.
This reverts commit bdddc94151.
This commit was not fixing the issue the proper way and was creating new
issues.
The real problem was that for very small increments at a time, a color
change could be perceptually identical to the previous color and
therefore not trigger color updates down to subclasses.
The reverted commit was trying to work around this by not updating the
GimpColorSelector color when it was perceptually identical (therefore
next check may be a bigger color distance), but this was definitely not
right. It was creating inconsistency in the stored color with the
actually selected one and that was the root for more issues.
See the next commit for a proper fix.
Oh and by the way, there was no leak, unlike what the reverted commit
message was saying. The old color was freed. ;-)
By default, the GimpColorSelect widget is set to show HSV with Hue
selected but we weren't selecting the channel which was defaulting to
"Red" of RGB. Therefore there was some inconsistency when first opening
the color selection dialog which was showing HSV colors on the left, yet
with "Red" selected on the right.
This fixes the inconsistency, which also allows parent or container code
to set the default they want (which is indeed RGB).
Do not only show the space, but also the model. For instance both RGB
and HSV can have the same profiles.
As for LCH, we must not show any space (it is based on CIELAB).
Note that I use the string "Model: %s" which is already used in
libgimpcolor, so I am not breaking string freeze. The "%s - %s" string
though is not localized, even though ideally it should be (and possibly
even be a better joining string in English), but I don't want to break
string freeze for this.
This issue is part of the fix for #10998, more as a UX issue than a bug
per-se. Depending on how you were selecting a color, now you might
select it as HSV, LCh or some other model (this was **not** the case
before, even though the GUI was similar. Yet the stored color was always
RGB. Now it's actually "whatever you choose"). As a consequence, it is
possible that choosing a color in another model may convert to slightly
different numbers, especially within decimal places. I don't think it
was the main issue, but it certainly doesn't help. Now we may be making
clearer what color model is being used in the GimpColorSelect color
areas.
gimp_size_entry_eevl_unit_resolver () loops through all valid units
to find a match for user's inputted value in GimpSizeEntry.
It runs until gimp_unit_get_by_id () returns NULL, where it does a
final check on GIMP_UNIT_PERCENT.
Due to a small logic error, we kept setting the GimpUnit to
gimp_unit_percent () each time it was NULL, so the loop ran forever.
Per Jehan, this patch breaks the logic up so that we terminate the
loop once the percent check fails.
As Cheesequake noted in !1673, there may be cases where one would want
to run gimp_help_connect() while also setting a tooltip. So they also
run gimp_help_set_help_data(), even though the latter is implied by the
former. Worse, it makes the order matter too much because if you call
gimp_help_connect() after gimp_help_set_help_data(), the tooltip would
be removed.
Now the reason is that gimp_help_connect() was clearly made to be run on
windows whereas gimp_help_set_help_data() was for other widgets, which
usually don't need to react to F1. Yet the previous commit does add
F1-connect for the lock buttons, which kind of makes sense. So why not
just add this tooltip argument.
As a side fix, I am removing a bunch of gimp_help_connect() on each
button in the layers effect popover. Just run it once on the top
container.
This patch resizes the selection mode
icons based on the user's icon size
settings. It creates a new function in
gimpenumwidgets.c to update sizes,
then connects to GimpGuiConfig's icon
size update notifications in GimpSelectionOptions.
Rather than trying to implement full i18n plural support, we just remove
this failed attempt from the past. The fact is that to get proper
support, we'd basically need to reimplement a Gettext-like plural
definition syntax within our API, then ask people to write down this
plural definition for their language, then to write every plural form…
all this for custom units which only them will ever see!
Moreover code investigation shows that the singular form was simply
never used, and the plural form was always used (whatever the actual
unit value displayed).
As for the "identifier", this was a text which was never shown anywhere
(except in the unit editor) and for all built-in units, as well as
default unitrc units, it was equivalent to the English plural value.
So we now just have a unique name which is the "long label" to be used
everywhere in the GUI, and abbreviation will be basically the "short
label". That's it. No useless (or worse, not actually usable because it
was not generic internationalization) values anymore!
Per Jehan, we should remove gimppickbutton-default.[ch] and
move the functions into gimppickbutton.c. Then we can
make the GimpPickButtonPrivate API actually private without
any additional public functions.
Temporarily reverting as the private struct
is shared between various OS versions of
the object and needs to be accessible.
A different approach will be needed to resolve,
and until then, I'd like the Debian pipeline to
work properly.
This fixes all our GObject Introspection issues with GimpUnit which was
both an enum and an int-derived type of user-defined units *completing*
the enum values. GIR clearly didn't like this!
Now GimpUnit is a proper class and units are unique objects, allowing to
compare them with an identity test (i.e. `unit == gimp_unit_pixel ()`
tells us if unit is the pixel unit or not), which makes it easy to use,
just like with int, yet adding also methods, making for nicer
introspected API.
As an aside, this also fixes#10738, by having all the built-in units
retrievable even if libgimpbase had not been properly initialized with
gimp_base_init().
I haven't checked in details how GIR works to introspect, but it looks
like it loads the library to inspect and runs functions, hence
triggering some CRITICALS because virtual methods (supposed to be
initialized with gimp_base_init() run by libgimp) are not set. This new
code won't trigger any critical because the vtable method are now not
necessary, at least for all built-in units.
Note that GimpUnit is still in libgimpbase. It could have been moved to
libgimp in order to avoid any virtual method table (since we need to
keep core and libgimp side's units in sync, PDB is required), but too
many libgimpwidgets widgets were already using GimpUnit. And technically
most of GimpUnit logic doesn't require PDB (only the creation/sync
part). This is one of the reasons why user-created GimpUnit list is
handled and stored differently from other types of objects.
Globally this simplifies the code a lot too and we don't need separate
implementations of various utils for core and libgimp, which means less
prone to errors.
Alx Sa