When using GIR-based bindings that will eventually include the header
files (like Vala), we need to make sure to tell the gir-scanner what
file that is. Otherwise tools like `vapigen` have to make an educated
guess (which will be wrong).
GObject introspection has issues handling random vfuncs (i.e. not part
of a GObject). Most of all, it needs to be able to give these a name
(so they can be used to cast in some higher level languages for
example). As such, give each vfunc in `GimpProgressVtable` a separate
typedef.
Copy gimp_param_specs_get_desc() to libgimp and make it also mention
default values. Don't install its header for now, because it's pretty
much a utility function of GimpProcView. It also doesn't handle most
GParamSpec types yet.
As a side effect, this fixed issue #3947.
… and additional source from python POTFILES.
These 2 fixes allow `make distcheck` to work fine.
You'll notice that I just commented the pygimp files out instead of just
deleting them. That's because there have been discussions and a patch
proposal lately about porting the pygimp API to Python 3/master. We are
not sure we want this yet for maintainability reason (and I was supposed
to be the one to wipe these files out!) but we'll see.
* Don't generate our own marshallers if they are available in GLib
already
* Don't set the c_marshaller parameter in `g_signal_new()` if it's a
default marshaller provided by GLib. See commit message of commit
39e4aa3c57 on why this is the case.
The first property of a GimpProcedureConfig is the related
GimpProcedure. All others are the procedure arguments.
Also fixing the pspecs index while looping since we want to start at 1
to loop through arguments for the same reason.
Among other things, this was breaking the calls to file_save() and
several unit tests.
(cherry picked from commit 48acb361a38cd5e5fd59f375d937910de2270dba)
like in the fix for issue #4392. Remove the reference to the issue
from gimp_param_spec_layer() because we can't have it in all places
that now do checks.
... property name validation.
Slightly different fix on master compared to the gimp-2-10 branch. Here
the GParamSpec creation will happen already on the plug-in process in
libgimp. Let's just make sure we abort before we segfault.
This will be enough for the plug-in developer to start debugging one's
code. At least the core process is not crashing when the plug-in dev
provides invalid param names.
in gimp_procedure_config_begin_export() and end_export(). It uses
both the "gimp-comment" parasite and gimp_get_default_comment() and
syncs them with the config's "comment" property if it has one.
as in, sync it with a "comment" property on the config if one
exists. Also allow gimp_procedure_config_begin_export() and
end_export() to skip GimpMetadata handling, for file formats which
don't support it.
No need to introspect deprecated API, especially for the new non-C APIs
after a major version update.
This also sync both the autotools and meson-generated GIR files.
See also #4018.
More of the files were wrong, or at least not absolutely identical to
the files generated by the autotools. I am not doing any code change
other than trying to make both build systems produce identical files
(except for slight differences on 2 files not worth the effort) even
though maybe some things can be improved (especially on the include
list). Maybe to be improved later.
Also fixing 2 of the previously autotools-generated files because of
space typos which should have been committed earlier.
Finally it is to be noted that there is no logics to copy the generated
files back to the source directory in the meson rules. I am not sure
anyway this is really worth it and maybe we should just stop tracking
these generated files eventually.
This is listed twice and is not needed for libgimpui (not listed in
autotools build) and apparently it provokes introspection warnings on
MSYS2 builds.
Thanks to lillolollo and Massimo for debugging this.
I had this warning when cross-building for Windows 64-bit:
> libgimp/gimpui.c:187:52: warning: passing argument 2 of
> 'gdk_win32_window_foreign_new_for_display' makes pointer from integer
> without a cast [-Wint-conversion]
> note: expected 'HWND' {aka 'struct HWND__ *'} but argument is of type 'guint32' {aka 'unsigned int'}
Similar to commit 9b328167ab. Apparently the same function is duplicated
into app/.
Also add some comments to detail a bit more where this Win32 different
comes from (i.e. bug 359538 on Bugzilla, commit eac61e1e12).
Moreover I tested the same steps as comment 4 in bug 359538 on master
code. The same hanging issue still exists with GTK+ 3.24.1 (in a Windows
VM at least). I have not investigated further, just wanted to check if
this ifndef could not simply be removed by now. Apparently not.
Thanks to Massimo for helping:
> To reduce the number of warnings down to 2, it is necessary to list
> gimptypes.h and gimpenums.h right after gimp.h and gimpui.h
> gimpuitypes.h at the start of libgimpui_headers_introspectable like
> they are in the corresponding list in Makefile.gi.
>
> Their order evidently matters
See #4018.
Some stuff are still wrong, but this is a first step in the right
direction.
export it to libgimp via GPConfig and add new API gimp_export_comment().
Bump the protocol version and improve variable names in both GPConfig
and libgimp/gimp.c.
Add gimp_procedure_config_begin_export() and end_export() which
are wrappers around begin_run() and end_run() and additionally
pretty much completely manage GimpMetadata handling.
A GimpProcedureConfig can provide boolean properties "save-exif",
"save-xmp" etc. in order to have them automatically managed by
begin_export() and end_export(). This also restores the feature of
overriding the procedure's saved default values with export
preferences, but not the values from the last export, like it
used to be in 2.10.
Move gimp_image_metadata_save_prepare() and save_finish() (which are
now completely handled by GimpProcedureConfig) from libgimpui to
libgimp, but keep their declarations in the libgimpui header. Not
perfect, but not finished either.
Also fix gimp_image_metadata_save_prepare() to set the affected
GimpMetadataSaveFlags to 0 when the image has no metadata at all.
They all had "class" as first argument (copied from gimpconfig-params.h)
and only worked accidentially because all functions they are used in
happen to have the right local "procedure" variable...
Add internal GimpProcedureConfig API to load/save "default values"
which are to be treated as if they were the hardcoded GParamSpec
defaults, but user-configurable. Also make all other load/save
functions available to other libgimp files.
In gimp_procedure_run(), if incomplete arguments are passed, don't
just complete them with the GParamSpec defaults, but look up the
user-saved defaults and use them if they exist. This happens before
everything else and brings back the PNG export feature of using
user-saved defaults also in non-interactive mode (but for all
procedures not just PNG export).
In GimpProcedureDialog, add "Load Defaults" and "Save Defaults"
buttons, they are the only way of managing the user-configurable
procedure defaults.
When clicking "Reset", show a popover with the reset options "Initial
Values" and "Factory Defaults".
and remember them internally between begin_run() and end_run().
Simplifies plug-in code even more.
Move the begin_run() before gimp_export_image() block in all export
plug-ins.
