Bump librsvg requirement to 2.40.6.
This was bug 620923 in librsvg, fixed from 2.40.6 as of commit
5ba4343bccc7e1765f38f87490b3d6a3a500fde1 in their master branch.
Similarly to what I did for CFLAGS and LDFLAGS in commit 20fdb8d, the
preprocessor flags for build tools should also be correctly defaulted
and used when building invert-svg.
... because LDFLAGS is ignored.
Firstly let's make sure that invert-svg build uses LDFLAGS_FOR_BUILD and
CFLAGS_FOR_BUILD; secondly, default these to LDFLAGS and CFLAGS
respectively when not-cross-compiling, unless values are explicitly set.
If the compiler supports destructors (which should cover at least
GCC and Clang), pair the call to babl_init() in gimp_widgets_init()
with a call to babl_exit() when the library in unloaded. This is
important in particular since the babl fish cache is constructed/
updated upon the last matched call to babl_exit().
This way we can be warned quickly about any AppStream issue (cf. bug
782759). This test requires web access for screenshot verification.
Packagers are invited to use --without-appdata-test option if they want
to skip the test (for instance if build environment has restricted
network access).
Use a code test inspired by libsoup configure test.
This is a hard dependency because HTTPS should not be considered an
option anymore. Nowadays most websites will use HTTPS by default, HTTP
gives SEO penalties and browsers are starting to display various
security warnings on HTTP websites.
Also the experience will be significantly degraded without SSL/TLS
support since the help browser will fail to load the manual remotely,
and opening various remote files on secure protocols will fail.
Note: the test cannot be performed while cross-compiling. In this case,
we will just display a warning for packagers to be at least well aware
of this dependency.
Even though the SVG loader is installed, it needs to be properly
registered for GdkPixbuf to find it. This is a problem for Windows where
the installation prefix can end up being anything and where the command
`gdk-pixbuf-query-loaders` is not run by any common component anyway.
Let's just warn the Windows packager to not forget to have the installer
run it if vector icons are enabled.
It is apparently not used for file type detection on Windows since
SVG detection worked correctly without installing this package. But
vector icons end up broken under MacOS when this is not installed
(thanks to Kris for testing this!). I assume this is necessary on
GNU/Linux too.
SVG icons won't be properly displayed with an older GTK+. See:
https://bugzilla.gnome.org/show_bug.cgi?id=781020
Note: 2.24.32 is not out yet, but it will be the first stable release
with the right fix.
... when building on Windows.
From bug 780270, comment 18:
I'm still having issue with Windows MinGW, but I have traced the issue
with the autoconf itself, and the autoconf-archive script
"ax_prog_cc_for_build.m4". I have written to the autoconf-archive
mailing list.
It seem that this script never worked as intended since a long time
because the way it works, it pushdef a few elements, then it disable
cross-compiling (for the following test), and invoke AC_PROG_CC (which
in turn invoke the code that find and set the exe extention). Then it
grab the BUILD_EXEEXT from that. This is neat and simple, but the issue
is that the autoconf AC_PROG_CC macro only invoke the code that is
responsible for finding the exe (and obj) extensions once (with
m4_expand_once). So, the end-result is that in the resulting configure
script, EXEEXT is properly evaluated, but when comes the time to
evaluate BUILD_EXEEXT, no test is performed to actually find the exe
(and obj) extension, even if the cross-compilation option changed (which
is the case for the duration of this test).
So, BUILD_EXEEXT will always end up blank (defined, but blank).
... shortcuts for non-English locales (e.g. Russian).
This will be fixed with GTK+ 2.24.32, which has not been released at
this time. Yet since it is only a configure warning, there is no harm in
triggering it already (not a hard requirement, it does not prevent
compilation).
Autoconf doc says: "Note that the source is evaluated exactly once, like
regular Autoconf macro arguments, and therefore (i) you may pass a macro
invocation, (ii) if not, be sure to double quote if needed."
We are way past the 2.31 that was in the check, and unfortunately we
can't get rid of the deprecated inline pixbufs until GIMP 3.0, so just
kill the useless check for good and never define
-DGDK_PIXBUF_DISABLE_DEPRECATED.
It was working fine for me, but someone had the error:
error: AC_PROG_CC cannot be called after AM_PROG_CC_C_O
/usr/share/aclocal/ax_prog_cc_for_build.m4:38: AX_PROG_CC_FOR_BUILD is expanded
from...
I can indeed see that AX_PROG_CC_FOR_BUILD code runs AC_PROG_CC again.
So let's make sure this is run before AM_PROG_CC_C_O.
Thanks to Francesco Riosa for reporting the bug.
As autoconf docs say: "like most Autoconf macros, they test a feature
of the host machine, and therefore, they die when cross-compiling."
Therefore use shell-type file existence instead which works for all
cases. This fixes configure failing with:
"error: cannot check for file existence when cross compiling"
From autoconf docs:
> ‘$target’ is for use by a package creating a compiler or similar.
> For ordinary packages it's meaningless and should not be used.
Since GIMP is not a compiler, nor anything similar, let's not make
anything from this information.
Thanks to Quentin Glidic for reporting the issue (on libmypaint bug
tracker, since it was using nearly the same code there too).
This commit also improves configure output regarding host detection,
and uses dedicated canonical variables $host_cpu/os instead of the full
value.
By default, it will now use xdg-email to select the user's preferred
email client, which means it only works on platforms with xdg-email.
The sendmail implementation is still available if requested explicitly
with --with-sendmail.
libmypaint just got ported to autotools, which makes GIMP again easily
built on all kind of platforms. There is no need to rely on older
versions of this library which would only give us headaches.
librsvg has too many bugs to be used for build-time SVG extraction.
So I will just leave out my extraction script (for the time being) and
simply commit all extracted SVGs (with Inkscape through a script).
The gray inversion script works fine though, so no need to commit
Symbolic-inverted icons.
Since we have many themes now, this new name better indicates that it
is meant to follow your desktop theme settings.
Also it will likely not remain the default theme.
It will makes nostalgic people happy. It does not change the plans about
the new Color icon theme, which we are planning to render pixel-perfect
as well in the end.
This will extract vectorial symbolic icons out of the SVG source, and
generate vectorial symbolic inverted icons too.
Vectorial color icons are not extracted yet.
I also make sure that the tools/ subdir is processed by make before
icons/ because a few build tools will be needed to extract the icons.
Yet I mark the feature as experimental because librsvg seems to be
broken on many edge cases and several icons end up wrong. I'll keep
the option experimental until I figure the right way to extract the
icons.
Initial version of our dark theme.
Additional credits for some of the UI images to horst3180 (Ceti-2 theme)
and Medhi Abhollahi (new CS6 II theme). All under GPLv3, as the rest
of GIMP.
Images originally created by Jakub Steiner and Barbara Muraus as the
"Art Libre" icon set.
The contributor jEsuSdA later worked on it.
It will now be available in the new icon theme selection through
preferences.
Many icons/size are still missing but this first commit makes a start
for complementary work.
so file-tiff-load and file-tiff-save are always built. Also move them
to their own folder plug-ins/file-tiff/ because they will soon share
some common GIO code.
Adding -Wreturn-type for general case, but also -Wsystem-headers to warn
of g_return_if_fail() on non-void, since these are macros from system
headers directory, and -Wreturn-type would not warn for these.
because it confuses gtk-doc and breaks some links. Also change the
"Index of new symbols in GIMP 2.x" sections to be what seems to be the
modern standard (looked at the GLib and GTK+ docs), and update some
other stuff.
The work-in-progress was using a source tree of libmypaint embedded
into GIMP tree. This is a cleaning with pkg-config test in configure,
and correct includes.
This does not mean that our patterns are all of a sudden "proper" now,
but the categories (except "Legacy") hopefully make sense for new high
quality patterns that will be added, and it's better than having them
all untagged.
Jehan