It's done, all Python plug-ins have been either ported to the new API +
Python 3, or they have been discarded (and moved to gimp-data-extras for
whoever wants to salvage them).
Let's get rid of the outdated pygimp directory (whose code has not been
built in the master branch for years now anyway)! Woohoo!
Current dev code of GEGL is necessary as it fixes its VAPI dependency
(see gegl!83). Without this, with a recent meson version, Vala plug-in
build fails.
See !334 for some more background.
Traditional -config scripts are awkward for cross-compilation, multilib
systems (lib/lib64), and multiarch systems like Debian; only one copy
of the -config script can be in the PATH. As a result, some OS
distributions are starting to deprecate or even remove them.
pkg-config is designed to be a replacement for traditional -config
scripts, and is cross-compilation-friendly: the PKG_CHECK_MODULES macro
looks for an architecture-specific executable like
x86_64-linux-gnu-pkg-config, which can look in an architecture-specific
search path for library metadata, before falling back to a generic
pkg-config executable.
As a bonus, pkg-config also compares version numbers correctly
(see #2454).
libwmf having pkg-config metadata seems to be a relatively new thing,
so I've kept the -config script code path too, using it if pkg-config
does not find libwmf.
Bug-Debian: https://bugs.debian.org/956183
Signed-off-by: Simon McVittie <smcv@debian.org>
To build GIMP without vala the arguments "--enable-vala=no --with-vala=no"
must be used during the configuration process. If the --with-vala is not
provided the build process will still try to build some vala based plug-ins.
Fixes https://gitlab.gnome.org/GNOME/gimp/-/issues/5389
These icons are not available in any of our themes (Symbolic or Color).
Also they don't seem to be available in many icon themes either actually
and I'm not sure GIMP properly fallbacks to system icon theme when an
icon is missing in the selected theme anyway (I think to remember this
used to work, but it doesn't look like it works anymore).
Anyway I just copied the 2 symbolic switch on|off icons available in the
GTK+ repository at gtk/icons/scalable/status/. These are supposed to be
used by GtkSwitch but somehow they aren't. So for the time being, let's
bundle them directly with GIMP (until we figure something better out).
I put them in hicolor because this is the generic/default theme which is
always used as last resort and is common to any theme. It means any
specific theme will be able to override these icons, but if missing,
hicolor will be able to provide a fallback.
The idea is to be able to advertize a new revision of the same version
of GIMP. For instance, this would apply when we release a
`gimp-2-10-14-setup-3.exe` Windows installer (then we are at revision
3, provided we started at revision 0).
The revision number is obviously only relevant to a given platform and
version. Also the concept of build ID allows to differentiate various
builds for a same platform, in particular to not look at revisions of
third-party builds. The build ID can be any string. Maybe we could just
use reverse DNS build id (such as "org.gimp.GIMP_official") to identify
the official GIMP build. So in the end, we only compare revisions for an
identical (version, platform, build-id) tuple.
Allows to disable the automatic update check at startup. I believe some
packagers will want such options, in particular on Linux distribution
(where they control their own release schedule and won't want GIMP to
pop new version warning up because they have been slow to update their
package).
Note that it is still possible to query version checks manually in the
about dialog, but the automatic check/popup is gone with this option.
GIMP will now process the remote gimp_versions json file to look if one
is using the last version of GIMP. This initial code doesn't act up yet
on this information. This will come in further commits.
Here are the characteristics:
- Since this requires internet access, a new checkbox is available in
the Preferences dialog, allowing to disable version checks. Note that
it is enabled by default as it is an important security feature, but
it has to be deactivatable.
- The remote access is done as an async operation because we don't want
it to block the startup in any way (for whatever reason). Also it
doesn't output errors if it fails to not be a bother (you don't
technically need internet access for an image program).
- We don't check at every startup. At each successful check, we save a
timestamp to prevent too frequent useless checks (I set it the timer
to a week or more for now).
The point will be for a packager to create a unique build ID to identify
the build or provenance. I also add a revision number so that we can
identify 2 builds from the same version/commit, same maker and platform.
It will also be used later to check for new versions (see "phone home"
feature #2584).
Separating autotools and meson commits for easy backport.
My previous test (commit 41285813a5) was a bit misinformed. So it turns
out bug #4185 is for all platforms and the broken libheif versions are
1.5.0 and 1.5.1 only.
So my new test (platform independent) is: prefer libheif versions with
profile support, except 1.5.x; then prefer lower versions without
profile support; and only as last resort accept 1.5.x versions (but
output a warning).
Known bug in libmypaint dependency. It has been fixed in libmypaint
1.4.0, which we cannot hard require unfortunately (Debian testing still
at 1.3.0).
Still let's make add a warning so that packagers are aware of the issue
and update when possible.
Replace the "Heif >= 1.4.0" line in the summary output by a comment in
the "Heif" line explaining this is about profile support.
Also add a >= 1.6.0 test and output a warning for Windows and macOS (cf.
bug #4185).
Bug discovered by Simon. See #3921.
The logics of the whole test for binding interpreters may still change
(or even disappear), but for now, at least make it work as expected.
So procedure:new_return_values() just seems broken with LGI. It doesn't
even look like it reaches the C code.
Anyway we can also just reconstruct the GimpValueArray, which works
fine. We now have official support for Lua plug-ins!
As discussed on IRC, I am not sure if really this is needed, since
theoretically we now have support for a whole bunch of languages without
doing anything (languages supported by GObject Introspection) and we are
not going to check for all of them.
Yet since now we install one JS plug-in, let's still do a quick check.
We'll see later if we want to change how we handle supported script
languages.
Rather than looking for pygobject-3.0 with pkg-config, run an actual
test in python, loading the 'gi' module.
I also added a version parameter making it possible to even check for a
required version of PyGObject, though it is currently unused (as I have
no idea if we have a minimum requirement for our plug-ins to work well).
This is an improvement of commit 8e938e0960 as I realized that we don't
need any development files, therefore I don't think that searching with
pkg-config was the right idea in our case.
If we decide to look for Python dependencies, we should also look for
pygobject as it provides the GI binding to Python.
I'm still not sure if we should look for these runtime dependencies at
configure time. But for the time being, if we continue doing so, let's
do it right.
We will fill this up with more examples of plug-ins in other languages.
Also we will improve a bit the examples to redirect people to source
code so that they understand what these plug-ins are.
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.
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.
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 particular, when header check fails, Python option is disabled.
Also let's use pkg-config to search for the Python include directory.
The reason is that include/python{version} is not always
true. On my system in particular, python3.7 was in `include/python3.7m`.
Jehan