Reduce number of undo steps created by Spryrogimp previews.
The implementation adds a function for clearing the
incremental preview drawing that is being executed as an idle task,
and closing an undo group in case the preview left it open (which
would usually be the case).
This is backported from the gimp 3 master branch. Replace the checkbox
of two saving options (keep layer, or redraw on last active layer),
with a combo box that has a third option for saving the pattern as a path.
paste as brush, paste as pattern, select to new brush, select to new pattern
fill selection outline, fill path, stroke selection, distort, rounded rectangle
indexed color conversion, merge visible layers, new guide, new guide (by percent)
image properties, newsprint, fractal explorer, sample colorize, new layer
metadata editor (just a button), spyroplus (only common buttons)
(cherry picked from commit 582801ccc5)
(cherry picked from commit b44c2e9352)
(cherry picked from commit cdd686f752)
(cherry picked from commit 3b818f6a9b)
(cherry picked from commit c7d5438b49)
Note from reviewer: sorry, this was not squashed on master! Gitlab
failed to squash even though the "squash commits" checkbox was checked!
So it ended as a 5-commit 1-line change!
:-/
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.
(cherry picked from commit 95044d86b3)
Pickle gimp.GroupLayer the same way we pickle gimp.Layer, so that
layer-group parameters can be properly saved.
All credit goes to Ofnuts :)
(cherry picked from commit b295a33aaf)
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.
(cherry picked from commit 9851bc8962)
... 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.
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
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)
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.
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.
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.
(cherry picked from commit dbb9555d2f)
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.
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.
... the python console.
It was using "selected text", which is most often inverted color (close
if not identical to the background color). As a consequence, it made
stdout output unreadable by default, forcing themes to always define a
style for the python console. Using "normal text" is a much better
choice to default to something readable from a parent style.
As a consequence, I also removed "python-fu-console" styling from the
System theme, where there should be as few theming as possible.
After commit f51acf3bfb the python console no longer
initialized gimpui, because it is no longer part of module
initialization.
If the plug-in is run noninteractively and it imports
gimpui explicitely it is now necessary to call gimp_ui_init ()
at the right time
...mergedimage.png
fix also the thumbnail creation, that:
must be 8 bit; should not be upscaled; should not have frame
or decoration, that I interpreted as when there are transparent
areas they should not be blended with a background color,
so instead of image_flatten use image_merge_visible_layers
(also for the merged_image)
Remove the invert-linear and invert-non-linear variants and simply add
"gboolean linear" to gimp-drawable-invert. This should actually be an
enum but I didn't find a good name right now...
and add gimp_drawable_invert_linear(). Also, finally deprecate
gimp_invert() and port all its uses in plug-ins and scripts to
gimp_drawable_invert_non_linear() so the result is the same.
...in both the core and libgimp.
Images now know what the default mode for new layers is:
- NORMAL for empty images
- NORMAL for images with any non-legacy layer
- NORMAL_LEGAVY for images with only legacy layers
This changes behavior when layers are created from the UI, but *also*
when created by plug-ins (yes there is a compat issue here):
- Most (all?) single-layer file importers now create NORMAL layers
- Screenshot, Webpage etc also create NORMAL layers
Scripts that create images from scratch (logos etc) should not be
affected because they usually have NORMAL_LEGACY hardcoded.
3rd party plug-ins and scripts will also behave old-style unless they
get ported to gimp_image_get_default_new_layer_mode().
By default, _DATA files are not included. Hence `make distcheck` fails
with:
*** No rule to make target 'pyconsole.py', needed by 'all-am'.
Let's add it back.
As a consequence of commit efae55a, plug-ins should not install
data/library files alongside on the root plug-ins/ directory. If they
have such files, they should create a subdirectory named as the entry
point file. Obviously we should be the first to follow this guideline.
We had one such plug-in: python-console.py, which is importing
pyconsole.py. Let's have both these files under
plug-ins/python-console/.
It was agreed that we should write "plug-in" consistently. Only possibly
user-visible strings were updated.
Thanks to scootergrisen for a first patch which could not make it
after changing decision on the canonical writing.
