We will fill this up with more examples of plug-ins in other languages.
Also we will improve a bit the examples to redirect people to source
code so that they understand what these plug-ins are.
Add gimplegacy-private.h to keep it separate from gimp-private.h.
The legacy code could now be removed and GimpPlugIn-ported plug-ins
would not notice.
Move all old wire code to gimplegacy.c and add wire code to
GimpPlugIn, which now talks with the GIMP core all by itself.
Add some more ASSERT_NO_PLUG_IN_EXISTS assertions to gimplegacy.c and
fix new code that was still using legacy API.
Especially as an example of setting a (rename-to) since variable
arguments are not introspectable, hence gimp_pdb_run_procedure() won't
be available for non-C plug-ins.
1/ First I realize we were still using AM_PATH_PYTHON() and not
AM_PATH_PYTHON3().
2/ We don't need to check anymore for pygtk, pycairo, nor do we need
Python headers. Everything is now taken care of by GObject
Introspection and we have nothing else to build GIMP-side.
3/ Change --enable-python into --with-python. We don't actually build
anything now. There is no Python support to enable or disable
anymore. We simply install Python plug-ins or not. The 3 values are
"yes" (default, configure breaks if a Python 3 interpreter is not
found), "no" (Python plug-ins are not installed, not recommended) and
"force" (install Python plug-ins anyway even if an interpreter is not
found; this can be useful especially for cross-compilation since
Python is not useful at build-time anymore).
Note that --with-python=force, if an interpreter is not found, the
file `pygimp.interp` won't be installed. This is not a problem at all
if the interpreter can be found at runtime the standard way.
Otherwise packagers should add themselves a pygimp.interp file with
the known interpreter path.
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.
Jehan