dallasgroot/Gimp
dallasgroot/Gimp
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
Gimp/plug-ins/python/Makefile.am

59 lines
1.4 KiB
Text
Raw Normal View History

plug-ins: port Python plug-in palette-to-gradient to introspected API. 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.
2019-07-28 09:29:42 -07:00
## Process this file with automake to produce Makefile.in
plug-ins: port python-console to new GObject-introspected API. 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.
2019-07-29 14:01:46 -07:00
SUBDIRS = \
python-console
plug-ins: port the core of foggify plug-in. 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. :-)
2019-08-27 17:25:19 -07:00
file_openrasterdir = $(gimpplugindir)/plug-ins/file-openraster
file_openraster_SCRIPTS = file-openraster.py
foggifydir = $(gimpplugindir)/plug-ins/foggify
foggify_SCRIPTS = foggify.py
plug-ins: improve Makefile.am of python/ subdir. The old rules were crap and basically copying the scripts in build folder before installing. Get proper/simpler rules.
2019-08-07 10:52:09 -07:00
palette_offsetdir = $(gimpplugindir)/plug-ins/palette-offset
palette_offset_SCRIPTS = palette-offset.py
palette_to_gradientdir = $(gimpplugindir)/plug-ins/palette-to-gradient
palette_to_gradient_SCRIPTS = palette-to-gradient.py
# TODO: to be ported:
## colorxhtml.py
## gradients-save-as-css.py
## histogram-export.py
## palette-sort.py
## py-slice.py
## python-eval.py
## spyro_plus.py
plug-ins: port Python plug-in palette-to-gradient to introspected API. 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.
2019-07-28 09:29:42 -07:00
if GIMP_UNSTABLE
plug-ins: improve Makefile.am of python/ subdir. The old rules were crap and basically copying the scripts in build folder before installing. Get proper/simpler rules.
2019-08-07 10:52:09 -07:00
## benchmark-foreground-extract.py
## clothify.py
## shadow_bevel.py
## sphere.py
## whirlpinch.py
plug-ins: port Python plug-in palette-to-gradient to introspected API. 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.
2019-07-28 09:29:42 -07:00
endif
plug-ins: add Python and JavaScript files to the DIST. 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.
2019-08-16 05:53:19 -07:00
EXTRA_DIST = \
plug-ins: port file-openraster to Python 3 + new API. 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.
2019-08-24 19:05:40 -07:00
file-openraster.py \
plug-ins: port the core of foggify plug-in. 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. :-)
2019-08-27 17:25:19 -07:00
foggify.py \
plug-ins: add Python and JavaScript files to the DIST. 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.
2019-08-16 05:53:19 -07:00
palette-offset.py \
palette-to-gradient.py
plug-ins: install the pygimp.interp file. 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.
2019-07-29 05:25:44 -07:00
# Python interpreter file.
pyinterpdir = $(gimpplugindir)/interpreters
pyinterpfile = $(pyinterpdir)/pygimp.interp
configure: fix the Python checks. 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.
2019-08-06 09:23:29 -07:00
if HAS_PYTHON_INTERP
plug-ins: install the pygimp.interp file. 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.
2019-07-29 05:25:44 -07:00
install-interp-file:
$(mkinstalldirs) '$(DESTDIR)$(pyinterpdir)'
echo 'python=$(PYBIN_PATH)' > '$(DESTDIR)$(pyinterpfile)'
echo 'python3=$(PYBIN_PATH)' >> '$(DESTDIR)$(pyinterpfile)'
echo '/usr/bin/python=$(PYBIN_PATH)' >> '$(DESTDIR)$(pyinterpfile)'
echo ":Python:E::py::`basename $(PYTHON)`:" >> '$(DESTDIR)$(pyinterpfile)'
install-data-local: install-interp-file
configure: fix the Python checks. 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.
2019-08-06 09:23:29 -07:00
endif
plug-ins: install the pygimp.interp file. 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.
2019-07-29 05:25:44 -07:00
uninstall-local:
rm -f '$(DESTDIR)$(pyinterpfile)'
Reference in a new issue Copy permalink