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.
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.
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.
Since GParamSpec are not working fine (cf. pygobject#227), we have this
trick of initializing new arguments or return values with properties.
Use this trick in the palette-to-gradient plug-in.
The way currently implemented plug-ins are, they are already
NULL-terminating the returned arrays. Since a procedure name cannot be
NULL itself by definition, defining the array length by a terminal NULL
is enough. There is no need to also add a n_procedures parameters which
is just one more possible bug source, even more as we were already
expecting the NULL termination by using g_strfreev() to free the memory.
Anyway a length parameter does not bring any advantage since a plug-in
can still "lie" about its array size (just as it can forget to
NULL-terminate it) and when this happens, the plug-in will segfault.
That's it, it's just a plug-in programming error.
Last but not least, some binding seem to have issues with returned array
setting an (out) parameter as the length. In pygobject at least, the
length parameter doesn't disappear and we end up with this ugly
signature:
> In [3]: Gimp.PlugIn.do_query_procedures.__doc__
> Out[3]: 'query_procedures(self) -> list, n_procedures:int'
See bug report pygobject#352.
To avoid this, we should either set both the array and the length as
(out) parameters or just set the returned array as NULL-terminated
(which is the solution I chose).
It's a bit weird because this has to happen during the query() step, but
plug-ins don't have access to this step anymore, apart from
query_procedures(), which then turns out to be badly named.
Several aspects of the new API are kind of broken in the Python binding,
especially the arguments. So this first version has no arguments at all.
This also means it cannot be installed in "<Palettes>" menu for the time
being. This is work-in-progress and the missing parts will be
uncommented later when we figure out how to fix the problems.
I may have missed things. That is the problem of non-compiled script
languages. There is also a known warning:
> DeprecationWarning: Gtk.Dialog.set_alternative_button_order_from_array is deprecated
I'll see later about this one.
Push-time note: calling various functions is actually broken right now
in the console since the late API changes (it was working fine yesterday
evening when I tested the same python-console code). Pushing anyway for
now.
Python scripts should already properly run, whether you run them with a
direct python shebang or a `env python` one (cf. previous commit). But
it's still nice to install a `.interp` file, which allows to control
exactly the interpreter to use, overriding the shebang. With this file,
Python scripts will use installation-time Python interpreter.
Also update old code to make the interp contents about Python 3 instead
of 2.
In particular, if the shebang is `#!/usr/bin/env lang` and we have not
registered a specific interpreter for `lang`, the system should leave
the env tool search the right interpreter for us. We only bypass env
when we set our own explicit interpreter.
Apply this to palette-to-gradient.py plug-in.
Localization still doesn't work, but this is normal (po-python is not
installed). I will later make the proper tests for this.
Other than this, it is a pretty simple port. It lost all particularities
and facilities of pygimp, but the fact that it now works similarly to
the C API is quite nice too.
It still uses the legacy API for plug-ins though and will have to be
ported further when the new API will be stable.
Also I still haven't figured out why we need to return the number of
returned values. With the proper annotations, an array length parameter
disappears in introspected Python (because it is useless as Python lists
know their length). But it would seem that this annotation doesn't work
the same for returned values, which is a bit sad as it creates ugly
redundancy.
It can be noted that I an going to move all Python plug-ins from
plug-ins/pygimp/plug-ins/ to plug-ins/python/. The whole pygimp/
subdirectory will actually be deleted eventually (I keep it around for
now as reference) as Python plug-in should not need to be considered
particularly from now on. They can just be considered as generic
executables.
