Cf !84. We don't want to just replace the old path without versionned
python, because I assume it has been set for a reason. So there may be
machines with a versionned python path, others without. Let's test both
on Windows.
The idea is that we already have a GimpProcedure object in libgimp
which has name, help, blurb, arguments, return values and everything,
so we really don't need a parallel API to query PDB procedures for
their properties.
- make run() a virtual function of GimpProcedure
- move GIMP_PDB_ERROR to GimpPDB
- GimpPDBProcedure is a trivial subblass which populates
GimpProcedure's members by querying the PDB.
- make "plug-in", "procedure-type" and "name" construct-only
properties of GimpProcedure.
This is all work in progress.
Oups, I left the plug-in as Python 2. This was still a good
proof-of-concept that GIMP 3 will support as well Python 2 and Python 3
(even though Python 2 is end-of-life soon anyway).
This first version will just offset by 1 in interactive mode, by
default. The GIMP 2 version used to have a GUI, but it was not created
by the plug-in itself. I am guessing that maybe our Python wrapper used
to create GUI by default.
If so, this will have to change. Python plug-ins will be responsible of
their own GUI, just like C plug-ins.
Older palette-to-gradient used to have a palette argument. Bring it
back. The logics is that if the string is empty or None, the procedure
will use the currently selected palette. Otherwise it will try to
transform the named palette into a gradient and will fail with an error
if this palette does not exist.
This partly reverts commit d999248d70.
The GimpStringArray is still very weirdly handled, in particular
regarding the difference of processing with static_data set or not.
Still this g_return_val_if_fail() was making more problems. It may come
back but will need more coding to handle the side effects.
See upstream report: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=13928
We are not making automake 1.16 a requirement as it is just too recent
and we don't want to break build on old machines. I will want to make a
better fix later.
For the time being though, at least let's test first the higher automake
version, then down to minimum requirement, rather than test first
required version.
Our GimpStringArray is so weird. We are obviously expecting it to be
NULL-terminated since, when we duplicate the data, we add one value.
Yet we were not checking that the stored data was NULL-terminated, in
particular when the string array is created with static data (in which
case, we use the input data as-is, without re-allocating).
Note that this doesn't fix the type mismatch Gimp.StringArray vs
Gimp.Array when introspecting.
We have code for this in gimp_proc_browser_dialog_new(), but it cannot
be moved in the object init() because this is a construction-time only
property. So this needs to be passed from the python call too.
Otherwise, if run in gimp_proc_browser_dialog_new(), this initial search
does not happen when constructing with g_object_new(). This is
especially bad for non-C plug-ins as gimp_proc_browser_dialog_new() is
not introspectable because of variable arguments.
As mentioned in issue #1777, exporting non-animated WebP images was
only keeping the current layer.
Mimick file-gif-save.c: display the encoding settings pop-up earlier
so that gimp_export_image() can merge the layers unless "As Animation"
is enabled. Call gimp_image_get_layers() directly in save_image() in
case the layers were merged (for clarity because layers are used only
for animations).
Which return proper GParamSpecs. Incuding some useless testing code in
gimp_procedural_db_proc_info(), to make sure things work, will go away
again soon.
Right now, we get the following warnings when building the docs:
> gtk-doc.xsl: For acronym (nullable) no value found
This is because we're not adding the generated annotation glossary to
the docs sgml (presumably because we didn't need it as we didn't use
GObject-Introspection yet). This commit adds those lines and thus fixes
the warnings.
Also generate comments like "Must be freed with g_free()" for all
return values instead of manually and inconsistently having them on
some return values only.
Jehan