It is a nearly full port. Some things would still need to be updated
(like deprecated use of GtkTable or gtk_range_set_update_policy()
removed), and other stuff need to be taken care of in GIMP API first.
But the core of the feature is there.
There are 2 TODOs to take care of here. First, there is no GUI yet for
the interactive mode which will just use the default values.
Second, the color argument is not working yet because I had issues
passing a GimpRGB as argument (ideally I should create a GimpParamRGB
with gimp_param_spec_rgb(), but since we still have the pygobject bugs
about manipulating GParamSpec data directly, I can't).
Anyway it works with default values, which is already a good first step.
:-)
Apart from porting, only code logics change is the whole
encode()/decode() code because it created a string vs bytes mess and the
zipfile API apparently didn't like to deal with bytes, even though the
docs say otherwise.
It's hard to test on my UTF-8 system, so please anyone working with
non-UTF-8 paths, we welcome reports if ORA load/save does not work
properly.
Other than this, load, save and load_thumb were all tested and working
properly so far.
So it seems that whatever is in _SCRIPTS is not in the distribution by
default (I suppose the reason is that even scripts can be generated). So
let's add the non-generated scripts to EXTRA_DIST.
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.
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.
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.
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.
