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!
... 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.
with proper value names. Mark most values as _BROKEN because they use
weird alpha compositing that has to die. Move GimpLayerModeEffects to
libgimpbase, deprecate it, and set it as compat enum for GimpLayerMode.
Add the GimpLayerModeEffects values as compat constants to script-fu
and pygimp.
Before commit 20523c61ac
PF_FILE used to open a "open file" filechooser dialog.
That commit, while adding the ability to open
a "save dialog" filechooser dialog using PF_FILENAME,
changed the behavior of the existing gimpfu PF_FILE type.
Restore the previous behavior and update the
built-in plug-ins using a save dialog to the new
PF_FILENAME.
FileChooser 'action' and 'buttons' should be consistent
and call set_alternative_button_order to be consistent
on platforms using the alternative button order.
Remove gimp_ui_init call from gimpui module initialization.
Add gimp_ui_init method to gimpui module and call it from
gimpplugin _run method before running the user code.
Rather than just discovering them by chance, a simple grep and some
search and replace are much more efficient! :-)
Cleaning only done on C and automake files.
