… gimp_image_set_simulation_profile().
It looks like NULL through the PDB for 'bytes' argument gets passed as a
GBytes of size 0 (which might be something I did, and to be fair, that's
fine; I just forgot having done this).
As a consequence, testing for NULL was wrong, and these 2 functions were
always failing with NULL. Now they behave appropriately.
I also improve the docs for both functions.
The function's documentation was already saying that we could set no
profile, except that in reality, setting NULL for the profile was simply
failing. Unless one checked the return value, the failure is also quite
silent. So let's actually implement what the docs say.
Also the concept of "default" profile might be a bit unclear in GIMP as
it could mean either built-in profiles or preferred ones (as set in
Preferences). I chose the former for this function, so I reword this
part of the docs.
… gimp_drawable_curves_spline().
We can now run directly "gimp:curves" operation, both destructively or
non-destructively, but also setting the TRC, as well as individual point
types (when the curve is of type "smooth" instead of freehand).
This is much more powerful!
Adds a GimpCurve object and functions in libgimp.
Rather than creating a GimpCurve object in core and
passing it back and forth, we just pass the attributes
and reconstruct it across.
In the future, we may combine this with the app/core one
and put it in libgimpbase.
The code to ban some filters for non-destructive usage was duplicated in
a PDB file and in the XCF load code. Additionally to combining these 2
codes into a single gimp_gegl_op_nde_allowed(), this commit also moves
part of the logic into gimp_gegl_op_blacklisted() which improves the
following:
* It used to be possible to create filters for hidden operations which
were not returned by gimp_drawable_filter_operation_get_available(),
such as "gegl:color" or "gimp:equalize", which would create all sorts
of problems. Now trying to create these filters through the API will
not work and will properly warn with an explicit error message.
I do not consider this an API break since the filters were not
returned in the available lists and therefore were not considered
usable. Anyone who would have used any of these hidden filters was
just going around a weakness in our implementation.
* We make sure that our lists of allowed/forbidden filters are
consistent across usages.
* When getting the list of filters with gimp_gegl_get_op_classes(), we
don't need to do an additional validation step (as we were doing until
now in the PDB call). This is meant to imply that all returned
operations were already validated.
Applies f78a0629 and b420a773 logic to
gimp_image_get_thumbnail () so it
converts higher bit-depth images to 8 bits
for GdkPixBuf.
This affects plug-ins like GFig which use
a full image preview, as well as thumbnail
metadata exports and image combobox
previews.
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.
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.
...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.
If the config object is NULL, we later face crashes! My guess is that we
had only been testing editing custom ops, but not creating them from
public API!
- The "Healing Brush" paper URL is dead. It now leads to one of these
horrible parasitic websites which reuse domain names. And we for sure
don't want to promote this! I'm using instead the associated page on
our developer website. I just created this page and right now it's on
testing only. But this will be the URL for the main website.
- The URL for the foreground extraction paper is still valid, but from
my small research today when writing various algorithm' pages, I think
our own implementation diverged from this original paper (though it
may still have part of this original paper's algorithm; only a deeper
check of the code would tell).
See: https://testing.developer.gimp.org/core/algorithm/foreground-extraction/
Also this PDB procedure is called generically gimp_drawable_foreground_extract()
and it even has an argument to choose the algorithm (even though right
now, there is only a single choice, which is "Matting" algorithm, and
even there you can't choose which one; it's always Matting Global;
Matting Levin cannot be chosen for instance).
So anyway it is not a good idea to point to one specific algorithm,
and even less to leave an external URL (which may also disappear some
day) in API docs. So I am just getting rid of this paper title and
URL, and replace it with actually useful information, which is how to
set the trimap to represent foreground, background and uncertain
pixels (note: I notice that it would have been different with Matting
Levin where uncertain pixels must apparently be set transparent).
Also fix a bit of "Since:" annotations, some minor spacing fixing and
remove one useless test (if we test if a type is an item, we don't need
to test the children drawable type).
This patch adds a GimpItemChooser widget
for use in GimpProcedureDialog Item parameter
GUI creation.
This will deprecate the existing
GimpDrawableChooser, as it covers all the
same cases plus others such as GimpPath.
Resolves#13598
Applies the same logic designed by Jehan
in f78a0629 to the gimp_drawable_get_sub_thumbnail
function.
This allows GimpZoomPreview and
GimpDrawablePreview in older
plug-ins to show correct previews for
images that are larger than 8-bit.
This bug had several causes:
* gimp_drawable_get_thumbnail_data() is pretty crappy as it just returns
dimensions and bpp. You get no real format information.
* When using it to create a GdkPixbuf, which seems like the most common
usage, only sRGB (with or without alpha) in 8-bit is supported by
GdkPixbuf.
So I'm just making sure that private _gimp_drawable_thumbnail() PDB proc
is only returning 8-bit sRGB(A) data. For thumbnailing, this is probably
fine anyway.
Fixes when calling gimp_drawable_get_thumbnail() on an item from a
high-bit depth image:
> LibGimp-CRITICAL **: 20:12:21.028: file ../../../../../../../dev/src/gimp/libgimp/gimppixbuf.c: line 112 (_gimp_pixbuf_from_data): should not be reached
We could have tweaked further the code to guess what is a meta file
procedure or not (what we have done until now) but I decided to be more
explicit and added gimp_file_procedure_[gs]et_meta() functions to
libgimp to tag a specific import/export procedure to implement a meta
format.
gimp_file_procedure_set_extensions() would still be used to list well
known formats using this meta format, for instance "hgt.zip" or
"xcf.xz,xcfxz" but the meta extension (simply "zip" or "xz"
respectively) would be used as such. No more "guessing" using the list
of extensions and assuming that at least one of them would have a dot
within.
… and reset their undo stack.
This is a followup to #14463 as I realized that images opened directly
by a load procedure may still be dirty, first if the plug-in developers
didn't think of cleaning themselves the image at the end, but even as we
add some metadata which adds an undo step too. So even if the plug-in
developer made a perfect job, the image would still end up dirty if it
has metadata!
Let's just make so that GimpLoadProcedure clean the image explicitly.
Note that other types of plug-ins creating images won't have such code
as we cannot anticipate every case. In fact, in some use case, maybe
someone may want a plug-in to return a dirty image with undo steps! At
least for load procedures, we can consider these pretty standardized,
knowing we want them clean upon loading.
See commit 822c26f709. We decided to solve #14463 by having
gimp_file_load() always force-clean the image and reset the undo stack.
Therefore fix the docs again.
I've been hesitating because we can consider this an API behavior
change. On the other hand, it just feels like an obvious bug. It makes
sense that all images loaded with gimp_file_load() are loaded clean and
without any undo history. So let's just fix it.
- Merging down a pass-through group onto a layer below does not make any
sense, considering how the below layer is the input to the
pass-through.
- Adding ability to blink problematic items when merge down fails. This
will help people to figure out what is the problem.
Without this, libgimp was creating raster GimpLayer objects when these
had been rasterized, which only made kinda sense when the old "discard"
procedures were not reversible. Yet even this was not entirely true,
since it was still possible to undo, but unfortunately these objects are
long lived. Once you get a GimpLayer, it won't ever change into a
GimpTextLayer (or others)!
So we need to have an object of the correct child type then we'll use
gimp_rasterizable_is_rasterized() to decide how to make use of the
object.
Share the whole rasterize logic of the text, link and vector layer into
an interface. I didn't write it as an abstract parent class, because we
might have more rasterizable items in the future, which may not be
layers (e.g. there were discussions of vector masks).
We need 2 lines in the PDB for it to be an empty line in the C file,
which in turn will be interpreted as markdown-like lists for the
gi-docgen generated HTML docs.
- Consistently add the text about inserting items into the image after
creation, with correct function links/references.
- Consistent grammar for function blurb.
- Make @name argument nullable for gimp_path_new().
This patch moves the enums for GimpTextOutline
and GimpTextOutlineDirection so that they are
accessible to plug-ins/scripts. This will allow
for us to add PDB functions to get/set text outline
properties.
… gimp_file_load().
We make sure that the load procedure associated to the file is the one
used for the inner-file (in case of imbricated files into container
formats).
Also let's set the imported file unless it's a XCF inner format.
