This is very similar to commit c6063183d3 from master branch, except
that I use the legacy tagged icon because GTK+2 does not have real
symbolic icon theme support yet, which means that I would actually have
to add the icon to all themes, and also revert colors and so on. That's
just annoying so let's just use the color icon here, which will be the
same fallback for all themes (even symbolic style ones).
The icon used is the update one from:
https://gitlab.gnome.org/GNOME/adwaita-icon-theme/-/blob/master/src/fullcolor/legacy/software-update.svg
Also I use now the same hicolor/ theme overlay trick as in master since
commit e815c615e1 so that I don't have to duplicate the work on all
themes.
Same as for the commit in master, licensing applies.
This icon comes from the Adwaita repository and is therefore licensed
under the terms of either the GNU LGPL v3 or Creative Commons
Attribution-Share Alike 3.0 United States License. See:
https://gitlab.gnome.org/GNOME/adwaita-icon-theme/-/blob/master/COPYING
Upcoming autoconf-2.70 exposes deficiency in configure.ac:
```
$ autoconf-2.70_beta2 && ./configure --host=x86_64-pc-linux-gnu
./configure: line 1430: 5: Bad file descriptor
checking whether is declared... ./configure: line 1432: ${+y}: bad
```
It happens because macros are called with parameters using insufficient quoting.
More details at https://lists.gnu.org/archive/html/bug-autoconf/2020-10/msg00027.html
The fix only amends `--with-linux-input`. Other cases of underquoting
will need to be handled separately.
Fix-by: Zack Weinberg
Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>
(cherry picked from commit cebeb90a87)
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>
(cherry picked from commit 00024db382)
Recent code changes depend on 2.56 symbols, and no one seemed to
complain for 2.10.18, so let's just bump the requirement.
Furthermore, 2.56.0 and 2.56.1 have a Windows-specific bug we were
testing for, so let's just bump straight to 2.56.2.
Add new Symbolic-High-Contrast and Symbolic-Inverted-High-Contrast
themes, which are automatically-generated high-contrast variants of
the (original) Symbolic theme. The contrast factor is settable in
the makefile, and is currently at 1.5 for both themes.
Rename tools/invert-svg to tools/svg-contrast, which now takes a
contrast-factor argument, and adjusts the input SVG contrast,
instead of just inverting it. Note that we can still use the tool
to invert icons, using a contrast of -1.
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.
(cherry picked from commit 7b5fff7861)
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.
(cherry picked from commit 315665592c)
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).
(cherry picked from commit 506a0476f4)
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.
(cherry picked from commit 73c09ebb32)
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).
(cherry picked from commit f051e6d238)
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.
(cherry picked from commit 5da252ca18)
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).
(cherry picked from commit 41285813a5)
Since this requires libheif 1.4.0, released end of February 2019, this
commit should not go into the gimp-2-10 branch right now.
(cherry picked from commit 22e14e0b9b)
Since this requires libheif 1.4.0, released end of February 2019, this
commit should not go into the gimp-2-10 branch right now.
(cherry picked from commit 22e14e0b9b)
Cherry-picked now anyway... If we allow new featues in 2.10, we must
also allow for a few updated dependencies.
