The GIR parser is giving warnings because both e.g. a signal, a
corresponding vfunc and a method emitting it are named
"channel_changed", which can and will give issues in some bindings.
The easiest option is to follow the general convention of starting the
signal emitters with `emit_`, which also makes clear the intention of
the method.
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.
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.
In pygimp/plug-ins/Makefile.am, fix the rule for the generated
plug-in files, so that they're re-copied to the build dir upon
changes to the source plug-in files.
When initializing a pygimp plug-in derived from gimpplugin.plugin,
only pass the plug-in's init() and quit() functions to gimp.main()
if the plug-in actually implements them, instead of passing the
default NOP versions. This avoids plug-ins that don't implement
init() from being registered as having an init function, causing
them to be run at each startup.
... from menus.
The script-fu version is still available through pdb (for scripts) and
even in the action search. But in menus, only the new Python version
will be shown. Also update the description and name of the old version
to make clear it is deprecated in favor of the new plug-in.
Finally rename the new version to simply "plug-in-spyrogimp" (dropping
the "-plus" part as we should consider it as a replacement rather than
as another plug-in, which the "plus" would imply). Anyway the old one
was called "script-fu-spyrogimp", so there is no name clash.
While at it, do some trailing whitespace cleaning in the new plug-in.
(cherry picked from commit 8729f9a662)
Comment by reviewer (Jehan):
This was submitted through gimp-developer mailing list, by the same
author as the original Spyrogimp in script-fu, but this time in Python.
It does more than the original plug-in, with some automatic preview (by
drawing directly on a temporary layer, not as a GEGL preview), and using
the current tool options (current brush, etc.). The new API is similar
yet different. The much evolved possibilities makes that I don't think
it is worth trying to map 1-1 the new API to the old one, so I just let
the old plug-in next to the new one, with a different name.
Note finally that the author also contributed a new Spyrograph operation
to GEGL, yet with the comment: "The GEGL spyrograph operation is very
basic, and untested from gimp. I intend to keep developing it, since I
thought that on-canvas interaction would be very user-friendly. However,
I am not sure I will be able to get it work in a way that makes the
on-canvas interaction interactive enough.
Even if I do, it will not do what the Python plugin can do. It will be
much more basic."
So let's just integrate this evolved version of Spyrogimp for now. :-)
See: https://mail.gnome.org/archives/gimp-developer-list/2018-September/msg00008.html
(cherry picked from commit 529583430d)
Add missing fclose invocations and fix copy-paste issue.
This issues has been discovered by coverity scan proceeded by Red Hat.
Fixed some mistakes in the patch and added more fclose() (Mitch)
(cherry picked from commit 56c8f8320d)
Do not set the interpreter to `python2` but to whatever was found by the
AM_PATH_PYTHON2() m4 macro.
It looks like the Python2 binary we ship in our DMG may be call "python"
only (without the '2'). Let's just make our code more resilient to
various builds.
I am not sure yet this is the only/actual problem for this issue on
macOS, but this is at least in the right way.
(cherry picked from commit 8f21c9483a)
The python path with directory are generated files and should not be in
the dist. The previous commit was fixing an in-tree `make check` but
this one fixes the `make distcheck` as the dist was packaging the wrong
python files.
(cherry picked from commit 55a7872e1b)
It seems I forgot to also install python plug-ins in a subdirectory
(because they are deactivated on master for the time being). I even
found a year-old patch from myself rotting in the tracker, and which was
doing exactly this.
I redid it, improved to fit changes.
Our configure test checks the presence of a Python2, but then uses
"python" as interpreter, which is a problem nowadays as the default
python is set to be Python 3 on some distributions (and this will be
more and more the case). So GIMP may end up trying to run our plug-ins
through Python 3 (which would fail) even if Python 2 is present.
Now AM_PATH_PYTHON2() m4 macro will set $PYTHON to a more accurate
Python version as priority.
Similarly let's use "python2" in the binfmt string for extension search.
(cherry picked from commit 03ea9cac54)
As noted by Massimo, we can just make the argument of raw_input() an
optional argument.
Also adding a modal implementation for input() so that it doesn't lock
the Python console waiting from input from the plug-in stdin. As noted
in Python doc, input() is equivalent to `eval(raw_input(prompt))`.
Not all that safe, but in the end, it is the developer's responsibility.
(cherry picked from commit 130ef5ce59)
Note: it is untested on master since we don't have Python right now, but
I don't see why it would not work here as well!
Ell