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).
Øyvind Kolås