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`.
So far only libgimpbase is introspected. It just works though (I could
test that I could just run a plug-in which could access libgimpbase API
without any problem).
The g-ir-scanner call outputs a lot of warning but I won't care for
these right now.
The `introspection.m4` is taken straight from GEGL tree.
In configure.ac, improve backslash escaping in the compiler
version string. Backslashes are currently not properly escaped in
our Windows builds, leading to spurious (and, in particular, non-
UTF8) characters in the compiler version string.
File extension (.gex) may still change if anything better is proposed.
This format is currently just a compressed archive containing the
extension data (plug-in, brushes or whatever) and the metadata file.
For now, opening such file will simply install it as a new extension,
keeping all file permissions and structure. Of course in the future, it
will have to trigger a confirmation dialog.
Currently the compression used is zip, which is just a first draft. This
is not a decisive choice as well. We could use some tarball compressed
in whatever other compression algorithm. I use libarchive as a new
dependency to support unarchiving as it seems to be a common library
(and since it is already used by AppStream-glib anyway, this doesn't add
any actual dependency, just make it direct).
Jehan