Since commit 89c359ce47, it's supposed to return a GBytes, yet it was returning
raw data (probably intermediate hacking state which was not properly cleaned
up).
It was crashing for instance GimpDrawablePreview widgets at drawing time.
It does absolutely nothing except sitting there, providing an is-a
relation (both ways because GimpData is its only subclass). This will
simplify having more libgimp API on GimpResource, without having to
add different PDB code for app and libgimp.
Much like for images and items. Change the PDB to transmit IDs
instead of names for brush, pattern etc. and refactor a whole
lot of libgimp code to deal with it.
modified: libgimp/gimpplugin-private.h
and Plug-in/Procedure Browser size.
gtk_widget_set_size_request () is applied to the dialog, as it does not
seem to bubble up from being applied to individual elements.
The existing 2.10 width/height values are used.
GLib has a specific type for byte arrays: `GBytes` (and it's underlying
GType `G_TYPE_BYTES`).
By using this type, we can avoid having a `GimpUint8Array` which is a
bit cumbersome to use for both the C API, as well as bindings. By using
`GBytes`, we allow other languages to pass on byte arrays as they are
used to, while the bindings will make sure to do the right thing.
In the end, it makes the API a little bit simpler for everyone, and
reduces confusion for people who are used to working with byte arrays
in other C/GLib based code (and not having 2 different types to denote
the same thing).
Related: https://gitlab.gnome.org/GNOME/gimp/-/issues/5919
Certain XMP metadata tags currently can't be saved by us until we get
support in gexiv2 for adding new structs not present in exiv2.
We remove these tags from the exported metadata because the XMPSDK in
exiv2 would otherwise fail to write all XMP metadata.
Examples are the newer (2019, 2021, 2022) sample images from the
IPTC Photo Metadata Standard.
We also add all the static functions present in gimpimagemetadata-save
at the top, which had been forgotten in the past.
1. gexiv2_metadata_has_tag with gexiv2_metadata_try_has_tag;
2. gexiv2_metadata_set_exif_thumbnail_from_buffer with the "try" version.
For a while now the minimum gexiv2 version for the master branch is 0.14.0,
which means we can replace these deprecated functions, since the new
versions were added in 0.14.0.
The GimpProcedureDialog API allows int and double SpinScales. However,
it calls gimp_prop_widget_set_factor () which requires doubles.
A conditional check for a double property was added to this call.
A check was also added to ensure int properties have a factor of 1.0.
- gimp_image_add_sample_point: guide is a left-over from copy-pasting and
add apostrophe
- gimp_image_get_sample_point_position: it was not clear that the
parameter was the y-offset and the return value the x-offset
The warning was:
> Warning: GimpUi: gimp_procedure_dialog_fill_scrolled_window: unknown parameter 'contents_id' in documentation comment, should be 'property'
- fix a typo s/Commponent/Component/.
- Add &std_pdb_compat() to the new PDB procedures (I realize that's probably
what the contributor was asking about, back in !446). Not sure if it's right
as there were none in this file, but these are clearly just wrappers around
GEGL ops, so it seems fitting.
- Some alignment fixes.
- More accurate "$since" variables.
(cherry picked from commit 66ef1ef1ef)
(cherry picked from commit dbf9f277a2)
Committer's (Jehan) updates:
- Component type is now int32 (int8 is not a PDB type available anymore).
- PDB files re-generated to handle changes in API and types.
This is not made to set the imported or exported file, but only the XCF file.
See previous commit to see what happens when this API is used to set non-XCF
file extensions (saving fails unless one edits the filename).
… don't include it from public gimpui.h.
As reviewed during !786, if this file is private, the name should show it
clearly. And of course, we must not include it from another public header, since
it won't be installed.
This also fixes building plug-ins with gimptool as reported by tmanni:
e00f2d7f50 (note_1650791)
Nothing was really clearly specified until now, which was kinda equivalent to
the string being in the OS encoding as used by GLib. Since this string will
usually be statically hardcoded in code (and not extracted from system), it's
just much easier to request UTF-8 for this specific case.
On Windows fopen () is limited to the current codepage,
GLib's g_fopen () instead accepts full UTF-8 by calling
_wfopen () internally (or a similar wide-char CRT routine).
When the core sends a NULL resource, which would be the default for object args,
hence is also what you get for the first call of a plug-in with a resource
parameter, libgimp was creating a GimpResource with NULL id, which is invalid.
It is much better to return NULL (since we made it so that NULL is a valid
value) and let the plug-in handle the NULL value as it sees fit for a given
parameter (they could just set the contextual resource for this type, or keep
NULL to mean "no resource selected").
This fixes failing to run plug-ins the first time (before any "last" values are
set). E.g. I had the issue when testing palette-sort.
Also I'm improving the error message when trying to use a non-installed resource
(it will now also print the resource ID and the error message). And the GError
was leaking in this case, so I properly free it now.
… moved to the implementation file.
When declaring with G_DECLARE_FINAL_TYPE(), the whole concept is that the struct
is made private (which also allows the type to evolve without breaking ABI if we
some day decide to make the class derivable). For this to make sense, the struct
goes in the implementation file, not the header.
For the rest, it's mostly alignment bugs and the like.
Fixes:
> libgimp/gimpresourceselectbutton.c:510:9: error: a label can only be part of a statement and a declaration is not a statement
> 510 | GimpResource *specific_value;
As well as some coding style bug (space after '*').
