In particular, for indexed images, color choice will happen within the
colormap.
The following uses are made context-aware:
* Test tool options color;
* Fill colors.
These other uses will not be context-aware:
* Padding, quick-mask and padding colors;
* Out-of-gamut colors;
* Generically generated color buttons (e.g. in filter dialogs);
* Foreground selection's mask color;
* Grid colors.
Looking in these tests, most are hard to test with just the API. These
will need to be properly replaced once we'll make use of a UI testing
framework allowing such tests.
Issue #15763 is again mostly false positive crashes of the unit tests
because the code is only partly GIMP code, arranged differently as what
a full GIMP process would actually do.
The new tests just runs on the real GIMP code. Now the difference is
that we don't test the UI by doing this, but this can be debated whether
the previous tests were actually running on the UI themselves (they were
mostly running some core code directly and sometimes activating some
actions or raising dialogs (gimp_test_utils_create_image_from_dialog()),
but again not by actually clicking or hitting keys as a human would do.
It's not proper UI testing (cf. #9339 of #13376 for further discussions
on this topic).
So in the meantime, let's go with this intermediate step. At least now,
such tests would run actual GIMP code and would catch issues which could
really happen in a GIMP process.
setlocale(LC_ALL, "") queries the user locale.
setlocale(LC_ALL, NULL) also queries the locale, but not the user
locale. It actually queries the programs locale, which by default is C.
Otherwise the user would need to have en_US.UTF-8 available no matter
what.
Check that derivates UTF8 of C locale aren't used as well.
Bug: https://bugs.gentoo.org/969468
Fixes: 88261f8b4c
Signed-off-by: Alfred Wingate <parona@protonmail.com>
file with INT16_MIN layer count
In PSD files the layer count is a 16-bit int that can be negative.
A negative value is a flag for transparency.
In our code, after setting the flag, we negate the value. However for
-32768 the minimum possible value, there is not 16-bit positive value,
so the value stays negative. This can cause a heap allocation failure
when we use this value to allocate memory.
To fix this, we check if the value is G_MININT16 and error out in that
case.
This function is counter-productive, since we now want to have both
deprecated and deprecated_since together. But there is no generic
"since version" to be used for such a macro.
So let's just have people explicitly add both variables (and error out
the generation script if they miss any).
… std_pdb_deprecated for previously deprecated functions.
The &std_pdb_deprecated() call won't set a "Deprecated since"
information since this can't be made generic anyway. We have the info,
it'd be a shame not to document it!
Also it clears the blurb and help string, which I find unhelpful (even
for deprecated functions, it's better to have proper documentation!).
I just realized that the way we have been using "Deprecated:" tag was
wrong. It has a version first, then further descriptive text.
Fixes display "Deprecated since: Unknown" in gi-docgen documentation.
I have manually tested each and every of the deprecated functions,
making sure we don't lose any feature. As expected, we don't. Having
dedicated libgimp functions may feel a tiny bit easier to call but this
is not scalable. We can't do this forever, with one function per filter.
And fortunately we won't have to, since now we can call filters on any
drawable directly! It also comes with the following generic advantages:
* It works with any filter, even third-party ones;
* We can also append filters non-destructively for later removal or
edits (the deprecated functions were always merging the filters);
* If the filter evolves, e.g. with new arguments, it should not affect
the API (though we should implement GEGL operation versions);
* If we don't need to set all arguments (e.g. leaving many args with
default value), the filter API may even be simpler and shorter;
* The filter API will be much less "opaque" thanks to argument naming
(rather than a long list of integers, doubles, etc.).
Specifically to the now deprecated functions, I noted the following
weaknesses on the deprecated API when testing:
* gimp_drawable_colorize_hsl() was missing a "color" argument;
* gimp_drawable_extract_component() had the enum argument "component"
set as an integer, which is particularly opaque when re-reading
existing code. Whereas the filter API uses generate choice strings
which are self-explanatory! For instance choice RGB Red is 0 with the
deprecated function but "rgb-r" with the filter API.
* gimp_drawable_levels() was missing "trc" argument (as noted in
#15681).
And as expected, no features are lost.
Note that I didn't deprecate the curves functions yet, because we need
to implement the GimpCurve type in libgimp first.
There are a few more functions which I didn't deprecate yet, because
they don't use a filter directly, but some core functions, though for
some of them, it is very likely they can be efficiently reimplemented
with the filter API too. I'll have to look closer at it. It looks like
we may have to implement GimpHistogram in libgimp too though.
… or a content to use as-is.
Until now, it was assuming the deprecated content was a function. So if
I want to deprecate in favor of a GEGL op (e.g. "gimp:levels"), we'd
have warnings showing a "Deprecated: Use gimp:levels() instead".
Now it will try to recognize the type of suggested replacement with a
basic heuristic: if there is a space, it'll just use the replacement
text as-is; else if there is a colon, it'll assume it's a filter name.
Else it assumes it's a replacement function, as it used to.
With an older configuration of a last run from before the new args had
been implemented, Curve Bend plug-in was crashing at start. The various
"*-point-*" argument were serialized as: (upper-point-x 0)
That meant an array of size 0 and that was enough to have the variable
load_settings_data set to 0 and therefore settings-data (which had the
real data) was never deserialized.
When system settings use , instead of . for decimal separation,
5753ac75 broke for legacy XCF grid parasites because numbers
were not encoded consistently. This patch brings back the
sanitation step with g_ascii_dtostr () that ensures all numbers
are saved with . decimal separation.
This was always planned, as outlined in commit 54d3beab9c. As a stroke
of luck, even though this default change had never happened, it turned
out that these 2 filters were always run in linear, when called from the
API (cf. #15681).
This is now fixed, and as a consequence, setting the default TRC to
linear would make sure that any script which was calling "gimp:levels"
with default "trc" would still run exactly the same (and if the prop was
set, it was broken anyway). As for "gimp:curves", it could not even have
been used anyway, because of the lack of the GimpCurve type in libgimp.
Therefore, plug-in API-wise, we can consider that changing the default
is actually the less breakage, which is good news as it fits our plans!
As for XCF storing of filters, since we are storing all the properties
anyway, it doesn't break XCF files with these filters either.
This last point was part of the mess discovered when handling #15681.
With both Curves and Levels, both the child operation class and the
parent class (GimpOperationPointFilter) have a "trc" property. When
setting these in the GUI, they are synced back properly, but not when
set by API.
This commit syncs the config's "trc" into the operation's "trc"
properly, not in the GUI layer.
Note that I had considered trying to get rid of one of the properties.
Having 2 props like this is kinda messy (as could be shown here). But
for now, let's just keep as it is and see later if we can do something
better.
With this commit, the "trc" argument on "gimp:levels" and "gimp:curves"
is now working properly, which is a first step in taking care of #15681.
Though it went OK in the GUI, this was completely interfering when
creating filters from API.
The problem was that in gimp_drawable_filter_update(), any property not
set is considered to be at its default value. And therefore if the core
operation's prop is not at default value, we reset it.
Where it went wrong is that if "trc" is first in the list of properties,
it may affect the value of "linear" (e.g. if "trc" is set to
GIMP_TRC_NON_LINEAR, then "linear" will be FALSE). And since it was
unchanged by the caller, this function will reset it to TRUE, which on
turn sets "trc" to GIMP_TRC_LINEAR.
Now I did consider a few alternatives, such as ignoring "linear"
properties in some cases (such as when "trc" was explicitly set once),
but this did not feel satisfying, and a bit random, or special-casing
the "linear" property for these 2 specific operations in this function,
but that felt too dirty.
In the end, I decided to simply render "linear" bogus, based on:
1. We don't use this property anywhere in the GUI already.
2. The main reason I can see in previous commits was to parse older
settings for these 2 filters; this won't be a problem anymore since
these settings will now be migrated to the new argument (see my
previous commit) and will therefore still render the same way.
3. This would have been a filter API breakage, except that both "trc"
and "linear" were not working correctly anyway and these filters were
always running as "linear" in GIMP 3.0 (cf. #15681), which I fixed 2
commits ago. So "linear" was already not doing anything in practice.
Based on all these reasons, I think it makes sense to deactivate this
property. We should remove it as soon as we are able to handle GEGL
property versions (allowing us to remove the property without breaking
the filter).
Note: this commit breaks the string freeze (sorry, translators!) for the
help string of "linear" property, but I think it is worth it documenting
that this property is now bogus (it was already outdated), and it's not
even really in the GUI (except in the filter browser, so primarily for
developers).
Property "linear" was replaced by "trc" in commit e09e563a70.
Unfortunately "linear" still stayed "as compat if needed for file
pasring" (cf. commit message) but this made a big mess, because when
setting operation properties at once, these 2 property can mess with
each other.
These migration rules are a first step in cleaning up the mess. Now we
should not have any config file with (linear) property in there,
therefore we can cleanly neutralize this property in further commits.
If we don't install it as a CONSTRUCT property, nor are we setting it
explicitly in the init() method, then it is never set (unless explicitly
set!), which often means the compiler sets it to 0, i.e. GIMP_TRC_LINEAR
for this enum type.
This was one of the issues which was explaining why these 2 operations
were always run in linear, even though the default was non-linear.
Note though that this fix is not enough. Now I even see the opposite: it
is always run in non-linear. I have more fixes in other parts of the
operations coming up.
Following 6245e4ee
In addition to producing testable packages by adding certain labels
(which only developers can do), now we can produce such packages by
adding the same label in the issue description. This facilitates to
non-developers generating such packages (e.g. new GsoC contributors).
While it was good to know the bundling is running fine,
this had the risk of people taking them as official.
So, let's be consistent with GNU Clang and Clang-CL builds.
