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.
Previously, we serialize/deserialized the curve values in the
"settings-data" GBytes parameters, ignoring the specific parameters
created for the procedure.
This patch adds code to check if they exist (non-interactively) and
loads them from the *-point-* and *-val-* parameters. Otherwise,
the "settings-data" parameter is used for backwards compatibility.
Going forward, the relevant curve values are stored in the individual
parameters rather than "settings-data", so that we're ready to remove
that parameter in GIMP 4.0. A deprecation warning has been added
to make sure we don't miss it.
Closes#14060
Alternative (legacy) approach to 96a65045e9
Flatpak 1.16 will take some time to land on distros so let's use --device=all
which is retrocompatible and recommended by Flathub linter for this use case.
The only problem is that the "sandbox cops" on our Flathub repo will complain
since we are allowing more devices than needed (even MIDI works as side-effect).
One point which was raised in #15681 is that the documentation is
lacking.
* Let's write down that the range of the point coordinates is in the [0,
1] range.
* Also let's rename num_points to num_coordinates because argument
points will actually contain 2 coordinates per points (so for 10
points, the points array will be of size 20). We also write that it
means that num_coordinates must therefore be even.
* Add more spacing in the docs and some better styling and annotations.
Not localizing it because anyway it doesn't look this arg is ever shown
in UI (there is another "trc" arg inside the config objects). But at
least fixing this typo because it's ugly.
This makes the macOS builds way faster (aprox. 1hr instead of 3.5hr)
thanks to local caching of GNOME runner. We, however, still need to
split them since the timeout is relatively small on such runner.
...and Gimp.heal ().
The "src-x" and "src-y" arguments for the
PDB Gimp.clone () and Gimp.heal ()
PDB commands belong to
GimpSourceOptions (which is a child of
GimpPaintOptions).
However, we were setting them to
GimpPaintCore instead, resulting in them
being ignored when cloning/healing via
the PDB.
This patch moves them to the correct
variable to be set, similar to how
1abb4543 moved "src-drawables" to the
GimpSourceOptions variable.
This was introduced in commit d4733e5b21. This was triggering a focus
grab each time we changed the color from within the FG/BG dialog, which
in particular had the focus being lost from said dialog. This is not
really good usability wise (and as a side issue, with some themes, the
focus change was apparently a bit bothering visually).
Removes the orig_list and orig_layers variables to simplify the export code, as these are
not used anymore, and advances the list variable to iterate through the layers list. Also
fixes a debug output line to make building with #define XMC_DEBUG work again.
Fixes issue #15645.
Since the COMMIT_SHA, we default to build with MacPorts which is more native.
But it is wise to not be overly reliant on it, since it tends to be very flaky,
and Mac platform have very restrictive hardware with software always changing.
