Also fixes the passing of the resource param definitions through PDB.
There was some weird assumption, with a comment, in commit 73733335c8
that this was unneeded, which meant that we were not able to properly
recreate the right param spec over the wire.
This abstract spec type is basically a GParamSpecObject with a default
value. It will be used by various object spec with default values, such
as GimpParamSpecColor, GimpParamSpecUnit and all GimpParamSpecResource
subtypes. Also it has a duplicate() class method so that every spec type
can implement the proper way to duplicate itself.
This fixes the fact that in gimp_config_param_spec_duplicate(), all
unknown object spec types (because they are implemented in libgimp,
which is invisible to libgimpconfig) are just copied as
GParamSpecObject, hence losing default values and other parameters.
As a second enhancement, it also makes it easier to detect the object
spec types for which we have default value support in
gimp_config_reset_properties().
As a side fix, gimp_param_spec_color() now just always duplicates the
passed default color, making it hence much easier to avoid bugs when
reusing a GeglColor.
The purpose of this flag is to have some procedure arguments for which
you wish to ignore last values, or restored values. This may be needed
for arguments which are really volatile and likely won't survive a
session (or even from a run to another).
This will be used in my next commit.
Note: this is very close to GIMP_CONFIG_PARAM_IGNORE, except that this
latter is used for obsolete properties instead, so I felt that it may
not have been the best idea to mix these semantically different flag.
Also GIMP_CONFIG_PARAM_IGNORE properties are not serialized but they are
deserialized, which is not exactly what we want (in most case, it would
work the same, but it also means that if last-used values were to
contain some deprecated value for a property for which we added this
flag, there would be at least one run where a buggy behavior would
happen).
… more robust.
GIMP_PARAM_NO_VALIDATE and GIMP_CONFIG_PARAM_DONT_COMPARE were the same
value, most likely because when GIMP_CONFIG_PARAM_DONT_COMPARE got added
(commit c5c807d191), the comment to keep in sync
libgimpbase/gimpparamspecs.h and libgimpconfig/gimpconfig-params.h was
missed.
Instead, since libgimpconfig can include libgimpbase, do the other way
around: first non-GLib param flags are in libgimpbase, then we add a
GIMP_PARAM_FLAG_SHIFT, then we increment from it in libgimpconfig, and
finally we increment from GIMP_CONFIG_PARAM_FLAG_SHIFT if ever we add
more flags in app/ (right now GIMP_SYMMETRY_PARAM_GUI is apparently the
only one, but this may change).
GimpExportOptions is incomplete.
It exists so the API is stable.
For now, ScriptFu eat and ignore actual args,
binding to NULL, in calls to PDB procedures
file-export-foo having formal args of this type.
Unlikely that in the future ScriptFu will do anything else:
if a plugin needs export options, use another language.
The few file exporters used by existing ScriptFu scripts
(file-gbr-export and file-pat-export)
don't honor export options.
- Fix annotations for gimp_export_options_get_image() to make it
actually introspectable with the GimpImage being both input and
output. Even though the logic doesn't change much (the input image may
be overriden or not), it doesn't matter for introspection because
images are handled centrally by libgimp and therefore must not be
freed. Actually deleting the image from the central list of images
though remains a manual action depending on code logic, not some
automatic action to be handled by binding engines.
- Add G_GNUC_WARN_UNUSED_RESULT to gimp_export_options_get_image()
because ignoring the returned value is rarely a good idea (as you
usually want to delete the image).
- Remove gimp_export_options_new(): we don't need this constructor
because at this point, the best is to tell plug-in developers to just
pass NULL everywhere. This leaves us free to create a more useful
default constructor if needed, in the future. Main description for
GimpExportOptions has also been updated to say this.
- Add a data_destroy callback for the user data passed in
gimp_export_procedure_set_capabilities().
- Fixing annotations of 'export_options' object from pdb/pdb.pl: input
args would actually be (nullable) and would not transfer ownership
(calling code must still free the object). Return value's ownership on
the other hand is fully transfered.
- Add C and Python unit testing for GimpExportOptions and
gimp_export_options_get_image() in particular.
- Fix or improve various details.
Note that I have also considered for a long time changing the signature
of gimp_export_options_get_image() to return a boolean indicating
whether `image` had been replaced (hence needed deletion) or not. This
also meant getting rid of the GimpExportReturn enum. Right now it would
work because there are no third case, but I was considering the future
possibility that for instance we got some impossible conversion for some
future capability. I'm not sure it would ever happen; and for sure, this
is not desirable because it implies an export failure a bit late in the
workflow. But just in case, let's keep the enum return value. It does
not even make the using code that much more complicated (well just a
value comparison instead of a simple boolean test).
This patch creates a GimpExportOptions class in both
libgimpbase and in libgimp. Currently it is a mostly empty
object, but it will be added to after 3.0 to allow for
additional export options (like resizing on export while
leaving the original image intact)
libgimp/gimpexport.c was removed, and most of its content
was copied into libgimp/gimpexportoptions.c. gimp_export_image ()
was replaced with gimp_export_options_get_image () in all
export plug-ins.
GimpExportProcedure has a new function to set the default
image capabilities for each plug-in on creation. It also sets up
a new callback function, which allows the options to respond to
user setting changes (such as toggling 'Save as Animation' in the
GIF or WEBP Plug-in).
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!
Fixes:
> libgimpbase/gimpchoice.c:366: Warning: Gimp: gimp_choice_set_sensitive: invalid return annotation
Introspection step is now fully without any warning! \o/
I thought that such annotations would work and be useful to tell GIR that
a type is nothing more than a NULL-terminated array of a specific type.
But apparently GIR doesn't like these annotations and complain. So let's
just clean these out.
Fixes:
> ./../../../../../../dev/src/gimp/libgimpbase/gimpparamspecs.h:254: Warning: Gimp: unexpected annotation: array
> ../../../../../../../dev/src/gimp/libgimpbase/gimpparamspecs.h:254: Warning: Gimp: unexpected annotation: element-type
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.
There are no plug-ins which uses GimpRGB for procedure argument, nor is there
any base PDB procedure. We don't pass this type anymore through from/to
core/plug-ins. So let's clean the whole code out as a next step to get rid of
GimpRGB from our codebase!
This is not seen on all distributions (mostly on Debian-based ones in my
experience), but some distributions install libraries in a second-level
directory under prefix (e.g. lib/x86_64-linux-gnu/ instead of lib/ or lib64/)
whereas our prefix-guessing code for relocatable builds harcoded moving up from
1 level.
This new heuristic will assume that if the leaf directory is neither bin/ nor
starting with `lib`, then it's likely a multiarch folder and we must move up
once more to find the prefix folder.
This should also fix the problem encountered by Bruno for the current work on a
potential official AppImage.
When running GIMP in the build environment (even before it's installed), we
don't want to "fix" paths. We had the case in particular on the macOS CI where
the install PREFIX was a parent directory of the build directory and therefore
we were "fixing" some perfectly good constructed directories (set by meson) into
non-existing folder paths.
Additionally this codepath should only run when ENABLE_RELOCATABLE_RESOURCES is
set (even though this alone would not have fixed our CI issue because the macOS
build is relocatable).
Finally I am updating the gimp-data repository so that libraries are properly
found from the (now correct thanks to this commit) paths set by meson when
running gimp-console from within the build directory.
...to fully use and return GeglColor.
Also, fix gimptext-parasite sending a
GimpRGB to create a GimpText instead of
the now required GeglColor, and update
documentation in gimp_checks_get_colors
to reference GeglColor instead of GimpRGB.
gimp_metadata_set_from_exif has special code for handling old-style
GIMP exif parasite data, but didn't check for the more common case
of loading exif data from image formats that can't be handled by exiv2.
The exif data in these formats usually start with the TIFF endian
markers instead of "Exif", which caused a failure to read this
metadata for e.g. EXR images, see issue #10903.
We change this function to check for "Exif" at the start of the data,
in which case we assume it to be the old-style exif parasite and in
that case add extra metadata as was previously always done.
In all other cases, we do not add extra metadata.
… accessed from Python.
Creating a new function gimp_value_array_get_color_array(). This should normally
not be needed (it isn't in C), but because of GObject Introspection limitation
and the fact that pygobject will automatically try to convert GValue to the
embedded value, we get this weird situation where the result is unusable in
Python for certain types. One of these types is GimpColorArray.
I suggest an annotation request to GObject Introspection:
https://gitlab.gnome.org/GNOME/gobject-introspection/-/issues/492
I think that with such annotation, followed as a second step by pygobject
support, correctly handling NULL terminated C arrays generically should be
feasible by bindings.
Though I had already implemented passing GeglColor through the PDB, it was not
complete. In particular, the protocol was not able to pass GeglParamColor specs.
Fixes:
> LibGimp-WARNING **: 16:06:09.451: _gimp_gp_param_def_to_param_spec: GParamSpec type unsupported 'GeglParamColor'
This is part of the fix to issue #10811, though it's not complete yet.
We pass 2 GeglColor through the wire now. Since it is passed very early
(when sharing the configuration), I had some issues with initialization
order of GEGL, and in particular when calling gegl_init() before
gegl_config() inside _gimp_config(), I had a bunch of such criticals:
> Plugin script-fu: GLib-GObject: CRITICAL: Two different plugins tried to register 'GeglOpPlugIn-transform-core'
Anyway in the end, I store the passed colors as raw bytes and strings in
the GPConfig object, and re-construct the GeglColor last minute in
_gimp_config().
Eventually this is meant to fully replace GimpRGB (as well as GimpHSV, GimpHSL
and GimpCMYK), both in libgimp and in core code, as part of both the space
invasion and the API rework. For this first commit, I keep this new object side
by side to GimpRGB.
Due to GObject Introspection we can't have the last part of an
identifier start with a digit, since that part will be used in Python
as the identifier, and Python doesn't allow that to start with a digit.
e.g. GIMP_ROTATE_90 would be used in Python as
image.rotate(Gimp.RotationType.90)
To fix this we add DEGREES in front of the number, without a '_',
even though that looks ugly.
With the sample image that contains the XMP namespace Item with the
correct url included, it is not returning the url when we ask for it.
This seems to be an exiv2 issue, but needs more research.
What GIMP doesn't do, is report that the namespace url we were looking
for wasn't found, and make sure that this doesn't block us from
handling all XMP tags.
To improve this on our end, we check if there was an error getting the
url, and if yes:
- We generate a warning message
- We create a dummy namespace url, with a special check for the missing
Item namespace to give it the correct known namespace url.
… a GimpProcedureConfig for arguments.
This also factorizes the code to load metadata. By default, a GimpLoadProcedure
will try and load metadata from a file (if Exiv2 knows the format). The run()
function will be allowed to edit the GimpMetadata object but also the load flags
before it is actually attached to the image, allowing plug-ins to have custom
metadata handling code when needed.
This is used in the generated GUIs for GimpChoice arguments, but also for
validation of property setting.
New functions:
* gimp_choice_set_sensitive()
* gimp_string_combo_box_set_sensitivity()
These will replace the int arguments used in place of enums. The problem of int
arguments used as list of choices is that it makes calling PDB functions very
opaque. This is especially bad when a list is long, so you constantly have to
refer to the documentation to understand what a series of numbers mean in
argument lists.
And the second issue is that plug-in developers have to manually maintain a list
of values both in the GUI and in the documentation string. This help text may
get out-of-sync, may end up with missing values or whatnot. Also if it is used
as tooltips, it makes for very weird tooltips in the graphical interface, with
an overlong technical list of int-values mapping which should ideally only be
made visible in the PDB procedure browser listing.
This will be used for creating limited lists of strings as argument types for
procedures.
Ideally enums are the best type for this, but it can only be used for generic
libgimp* enum types, not custom enums created only for a given plug-in. For
this, we currently just demote the args to ints which lose any semantic. A
limited list of string will give back some semantic and some better validation,
even though it's a tiny bit more annoying to work with strings than int types
(at least in C).
Some images have Exif.Photo.PixelXDimension and Exif.Photo.PixelYDimension
metadata tags in addition to Exif.Image.ImageWidth and
Exif.Image.ImageHeight (mainly tiff images). So far, we were not updating
these optional tags, meaning they could get out-of-sync with the actual
dimensions when resizing and then exporting the image.
Since these tags are non essential, we will only update them if they are
already present.
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
Our metadata library exiv2 only registers the most commonly used xmp
namespaces. Other namespaces need to be explicitly registered. We did not
read or try to store these namespaces, which caused a lot of warnings about
"No namespace info available for XMP prefix '...' and then we could not
process that metadata or save/export those tags.
We had to wait for gexiv2 support for registering/reading namespaces, but
that was added in gexiv2 version 0.12.2 (and the "try" version in 0.14.0).
When reading xmp metadata we process all namespaces and add them to our
metadata xml when we haven't seen them before in the same image.
A GHashTable is used to keep track of the prefixes we have seen before.
The new namespace xml tag is skipped in older GIMP versions, but will be
used now to add the namespaces when exporting images with xmp metadata.
We were using fixed size buffer with strcpy/strcat, which gave warnings in
coverity.
Even though in our case there was no chance of buffer overflow, let's
replace this by using g_strconcat, which allocates memory for the
string which we free after use.
Also get rid of a few unneeded memset's for strdata.
Alx Sa