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).
We currently have brush and pattern I/O code in both the core and
plug-ins. This commit starts removing plug-in code in favor of having
one copy of the code in the core, much like XCF loading and saving is
implemented.
Add app/file-data/ module with file procedure registering code, for
now just with an implementation of file-gbr-load.
Remove the file-gbr-load code from the file-gbr plug-in.
Older --enable-binreloc configure option had basically the same purpose
as the newer --enable-relocatable-bundle, though the old binreloc was
only used for gimpenv.c code.
As a consequence, commit 10ce702188 was still not working fine since
gimp_installation_directory_file() also need binreloc enabled (to be
actually relocatable).
Let's get rid of this whole mess, by implying we want binreloc code to
be used when --enable-relocatable-bundle is ON. We don't need the
m4macros anymore, since AM_BINRELOC was basically just checking that
`/proc/self/maps` was present. But anyway being present at compile time
does not mean it will be at runtime (nor the opposite). So this test is
not that useful. The binreloc code will anyway fallback gracefully to
the non-binreloc code (i.e. trying to use build-time install paths) if
the procfs is lacking at runtime.
Before each release, we prepare now a <release> tag. Unfortunately some
details are not always well known for sure in advance, in particular the
date of release (plans are made to be broken!), and also the release
news URL (since the date is in the URL). So I usually leave them as TODO
and until now, I never forgot to update them just before release. But
there is always the risk of forgetting.
Now the test for the appdata files will also look for remaining "TODO"
in the file if and only if the micro version is even (which means it's a
release). So we won't ever forget to update the file as long as we run
`make check` on the last commit (which we always do obviously).
When constructing CC_VERSION, escape backslash characters in the
compiler version string, so that they don't get interpreted as
escape sequences by the compiler. This is especially important on
Windows, where the version string of MinGW may contain backslash
characters as part of paths.
This is a runtime dependency. If absent, we simply won't have access to
the alternative Matting Levin engine in the foreground selection tool.
If we don't add a test in configure, this may be easily forgotten. I
created the `gegl --exists` feature specifically for this kind of
checks, so let's check operation existence.
The Windows backend produces full, multithreaded backtraces. When
DrMingw is available, it also provides full symbol and (where
available) source-location information. Otherwise, it provides
symbol information for most of our libraries, but not for the GIMP
binary itself.
GimpBacktrace provides an interface for creating and traversing
multi-threaded backtraces, as well as querying symbol information.
While we already have some backtrace functionality, it relies on
external tools for the most part, and as such is rather expensive,
and is only meant for producing opaque backtraces. GimpBacktrace,
on the other hand, is meant to be relatively cheap (we're going to
use it for profiling,) and allow inspection of the backtrace data.
In the future, it might make sense to replace some, or all, of the
other backtrace functions with GimpBacktrace.
GimpBacktrace currently only supports Linux. By default, it uses
dladdr() to query symbol information, which is somewhat limited (in
particular, it doesn't work for static functions.) When libunwind
is installed, GimpBacktrace uses it to get more complete symbol
information. libunwind is currently an optional dependency, but it
might make sense to promote it to a mandatory, or opt-out,
dependency, as it's lightweight and widely available.
On other platforms, the GimpBacktrace interface can still be used,
but it always returns NULL backtraces.
The jpeg_save_markers API has existed since 27th March 1998! So it's
safe to assume that everybody has it, and there's no need to check for
it.
libjpeg-turbo has had a libjpeg.pc since 2016, and the IJG's software
has it too. Dropping support for old libraries is a small price to pay
for the benefits of a simpler build.
https://gitlab.gnome.org/GNOME/gimp/merge_requests/28
We don't need to commit PNG symbolic icons as `gtk-encode-symbolic-svg`
is perfectly able to generate them from the SVG.
Moreover its man says that it makes "specially prepared png files",
whatever that means. So I don't think we should just rename our
self-exported PNG files as '*-symbolic.symbolic.png'. It is better to
generate them with this tool.
Note that I am now splitting icon-list.mk into 2 files. This is only a
temporary stepback, as I am actually going to merge the 2 icon themes
into one very soon, and hopefully we should be able to generate the list
to ensure we don't miss an icon.
Anyway the icon lists had already diverged earlier, even though it was
only all still in a single file.
... Windows installation of GIMP.
Our default installer installs 32-bit version of the various DLLs in
32/bin/ (under the installation prefix). Currently this additional
folder is simply added in the PATH, so it works most of the time.
Unfortunately the PATH is searched last for DLLs, and in particular, it
is searched after system directories. So it means that if any misbehaved
application is installing DLLs in system dirs (and in particular
incompatible/older versions of the same DLLs a GIMP plug-in uses), it
breaks the 32-bit plug-in.
SetDllDirectoryW() bypasses this order and the set folder is searched in
between the binary directory and the system dirs. We were already
setting this for our main bin/ directory, which was good for 64-bit
plug-ins, but this was not protecting 32-bit plug-ins. Now our code to
run plug-ins check the bitness of the executable before running it, and
updates the DLL folder accordingly.
The alternative 32-bit folder can be overridden by the configure option
--with-win32-32bit-dll-folder (default: 32/bin/). This option can only
be set when building for 64-bit Windows obviously.
Alternatively we could have put copies of 32-bit DLLs in a subfolder
with each 32-bit plug-in, but this is at best a terrible workaround, as
we would duplicate DLLs for every such case. And this would not have
protected third-party plug-ins which wish to use some of our DLLs.
Last alternative is to use AddDllDirectory(), but it works since Windows
7 with a given update only. And our current official support is any
Windows since Windows 7. So we don't want to use this right now (also
I'm not sure it would actually be much better than current
implementation, and it seems to have a bit more limitations than
SetDllDirectoryW(), though I have not tested).
(cherry picked from commit 91c139f4d0)
Debugging stable versions under Windows is a pain because we don't have
access to the standard outputs. The debug console is indeed only built
on unstable builds. Let's make the debug console a separate build option
to allow building stable versions for debug (obviously the default
behavior when not configuring, is same as before, i.e. stable without
console and unstable with console).
(cherry picked from commit 1a28878943)
AM_PATH_GLIB_2_0 m4 macro actually computes this value using
$PKG_CONFIG. Yet $PKG_CONFIG variable is the pkg-config tool looking for
target libraries (not host), hence it would return the executable
`glib-compile-resources` built for the target.
Also using the same variable name invalidates our test: our own
AC_PATH_PROG was never run as the variable was already set. And no
environment variable could override this test anymore either. This is
why I rename the test variable to HOST_GLIB_COMPILE_RESOURCES.
(cherry picked from commit d1d9eb17e5)
Back when I implemented this as a recommendation, gettext 0.19 was not
even out yet. Nowadays it is in Debian Testing (Debian Stable even!), so
it makes no sense to continue just "recommend" it, especially as it was
breaking script-fu localization.
See old commit feb1bf2797.
Right now it only loads AppStream data, which is completely useless, yet
is a base of a managed extension system. Having proper metadata is what
will allow to actually know what is installed.
This is only the first draft.
Note that I am not adding the extension path into GimpCoreConfig on
purpose, since the point is not to have people manage their extension
directories manually anymore.
The extensions will be loaded from the build-time system path or the
config directory, and that's all.
What will probably be stored in the config though will be the remote
repositories URLs (allowing third-party extension repositories).
... --enable-relocatable-bundle option.
This will allow to use this option for more than MyPaint brushes. For
macOS and Windows, we default to "yes" and "no" for other OS, though it
is always possible to set an explicit value.
This is the minimum set of changes needed to update help-browser to the
WebKitGTK+ 2 API. Fortunately, the plug-in did not use parts of the old
API which would have been difficult to port (DOM bindings, for example),
and therefore the code translates quite well to the new API. The main
differences are:
- WebKitWebFrame is gone, most of its methods are now in WebKitWebView.
- Searching for text inside Web pages has to be done now through the
WebKitFindController object.
- Checking whether there is selected text that can be copied now goes
through WebKitEditorState.
- The WebKitWebView::title-changed signal is no more, the callback is
connected to notify::title instead.
- The load-started and load-finished pair of signals are now merged
into WebKitWebView::load-changed.
- There are no methods to zoom a WebKitWebView in and out, instead
the zoom-level property is set. The updated code ensures that the
zoom lovel stays inside the [0.1, 10.0] range.
- Page visit history now goes through WebKitBackForwardList.
The updated plug-in was successfully built in tested with WebKitGTK+
version 2.20.3.
Commit b2df13749c disabled building
devel-docs and pygimp in the makefiles, but their makefiles are
still generated by configure, which breaks distcheck, because the
necessary Makefile.in files are missing from the tarball.
Comment out the skipped files in configure.ac too.
These were mostly kept for scripts which needed to keep working. Since
we don't ensure compatibility anymore, let's just get rid of old
deprecated data.
These are not working anymore since we now need CSS themes.
Also we'll prefer to use theme variants anyway.
I also remove a remnant of the old "Small" theme, which was not
installed anymore anyway, and is not useful anymore.
We have this problem with flatpak that the common directory
("/usr/share/color/icc") is not visible from inside the sandbox. With
proper permissions, it is actually accessible, yet the host's /usr is
mounted at /run/host/usr/.
Since sandbox systems are getting more common, we need to make this path
customizable. I am therefore adding a --with-icc-directory configure
option to change the default color profile folder at build time.
See: https://github.com/flathub/org.gimp.GIMP/issues/15
We get a lot of packaging bugs for third-party builds in our tracker,
especially since our debug tool now opens directly our bug tracker.
It would be preferred if third-party packagers were to make a first
filtering of bugs and only reported once they knew for sure that the bug
is in core code, and not in packaging.
Our configure script will now propose a --with-bug-report-url option
allowing to set a different web address. This address will be the one
opening in the debug dialog.
... drive roots (e.g. C:\, D:\, ...))
This is a regression of glib 2.56 (not applying to 2.54 since it is new
code). It has been fixed recently in what will be 2.56.2 but is not
released yet, so we can't just bump the requirement.
Since it is a pretty bad bug though, let's add a test specifically for
these versions in the configure script so that nobody will package these
versions of glib. We can remove this test when we will bump the glib
requirement.
Thanks a lot to Dirk for contributing this, added him to AUTHORS.
Import the code from https://github.com/strukturag/heif-gimp-plugin.git
as of today. Merged the files into a single-file plug-in. Changed
the code a lot to match our coding style, but only formatting,
no logic changes.
Still uses deprecated GimpDrawable API and no GIO, but I wanted to do
actual code changes separately from the initial import. Also disabled
metadata support because updating that to GimpMetadata was too much
for the initial import.
because a simple platform dependency in gimpcoreconfig.c doesn't do
the trick (there can be both manual builds and bundled builds on
windows and macos). Use an AC_DEFINE() instead.
Also, make sure the system gimprc and its manpage are generated with
the correct values.
Some gimprc properties' default values depend on the machine where
"make dist" in run. We had an ugly hack in place to force
(num-processors 1) in the installed system gimprc and its manpage, but
were still leaking "tile-cache-size" and "mypaint-brush-path".
The files are generated by the hidden options --dump-gimprc-system
and --dump-gimprc-manpage which exist only for this purpose.
In gimpconfig-dump.c, special case the three properties in
dump_gimprc_system() and dump_gimprc_manpage() to output constant
default values for "num-processors" and "tile-cache-size" and
output @mypaint_brushes_dir@ in "mypaint-brush-path" which can
be replaced at configure time.
Also introduce etc/gimprc.in so @mypaint_brushes_dir@ can actually be
substituted for the installed system gimprc.
This was hard-coded to what I guess was a personal prefix (commit
368c7c0511), which is obviously wrong. This has to be constructed at
compilation and the man must mirror whatever is the actual installation
path of mypaint-brushes package.
I hesitated keeping both the pkg-config and freetype-config (which is
mostly a wrapper to pkg-config nowadays apparently) as fallback, but
anyway I can see in their repositories that they have a pkg-config file
since 2003. Really I don't think it makes sense to hold onto such old
and deprecated dependency configuration systems.
Move gimp-debug-tools.c from tools/ to a new app-tools/ subdir,
which should contain external tools needed by app/, and which is
built *after* app/ (unlinke tools/). This allows gimp-debug-tool
to depend on libapp and libappwidgets, instead of on actual source
files from app/. Building sources from app/ in another subdir
screws with the distclean rules, and breaks distcheck.
If running for instance in a cross-compilation, I need to make clearer
the fact we are looking for a native GEGL and also that we are looking
for the executable (used during the build), not the library. This is a
different test as the one for the library with PKG_CHECK_MODULES (which
looks for the target platform's library).
gimp_spawn_async() is similar to, but more limited than,
g_spawn_sync(). Unlike the latter, gimp_spawn_async() uses
vfork(), instead of fork(), when possible.
On Linux, a process that uses large amounts of memory (as GIMP may)
can hang during a fork() if overcommitting is enabled, and there's
not enough memroy. Using vfork() avoids that, since it doesn't
duplicate the parent's address space.
On Linux, when /proc/sys/kernel/yama/ptrace_scope is 1, a process
may only ptrace its descendants by default, which prevents the GDB
process spawned by gimp_stack_trace_print() from attaching to, and
producing a backtrace for, the calling process.
Use prctl() with PR_SET_PTRACER, when available, in the parent
process, to allow the child process to ptrace it.
In a previous commit, I bumped it for Windows only, where major bugs had
been fixed in recent fontconfig. Yet as Mitch notes, Debian testing has
Fontconfig 2.12.6, so we can simply use the same requirement on all
platforms. No need to make our configuration script over-complicated
with per-platform requirements here.
Fontconfig has a new slowness issue, this time apparently because of
locked cache files, preventing a successful cache update.
See: https://bugs.freedesktop.org/show_bug.cgi?id=99360
Furthermore the slowness apparently happens at every GIMP startup, and
also even when GIMP closes according to various reports. So let's bump
Fontconfig version (for Win32 builds only).
Also let's not make it a recommendation anymore, but a requirement. That
makes quite a few Win32-specific fontconfig bugs which have been fixed,
and most are quite serious so this should not be considered as optional
anymore, I guess.
It is nice because when available (Linux only?), it is a lot faster than
using a dedicated debugger such as GDB or LLDB, and also it allows to
always have a backtrace, even when no debuggers are installed.
Unfortunately the output is a lot less detailed, with no file paths, no
line numbers (even when debug symbols are there), no local values
printout, etc. It's pretty bare, with function names and the stack
levels. This is why it is not given priority, and GDB and LLDB are still
preferred when available.
I completely forgot to rename the appstream file according to the new
ID. While doing so, I also make it a .in.in file, with initial
processing by the autotools. Indeed I need @GIMP_COMMAND@ to be replaced
by AC_CONFIG_FILES().
Finally I fix a badly closed XML tag (which reminds me I should always
test a commit, even when it's a simple non-C 1-liner change!).
This makes no functional differences since this package has a pkg-config
file only since 0.4.7, our current requirement. This means that
searching for any poppler-data through pkg-config is the same as
searching for this minimum version.
But at least that makes for better output in case of error. People who
wish to build GIMP will have proper error information of the minimum
requirement for poppler-data.
This ensures that MyPaint default brushes are installed, otherwise this
makes the MyPaint brush tool quite useless and confusing unless MyPaint
is installed (which was making MyPaint a de-facto dependency of GIMP
until this commit!). Also we won't have to guess anymore the right path
for these brushs. The path will be known at compile time.
