See the commit 28467cb on the gimp-data-extras repo where I moved this
data in. Not sure why this metadata file was ever pushed to the main
repo as it is obviously for the data-extras package (or else I am
missing some information!).
The old 2017 report where it was originally added:
https://bugzilla.gnome.org/show_bug.cgi?id=763398
As told to us, this is the reference AppStream file testing tool, and it
understands more of the spec.
Also since commit 73e2e701da, appstream-util chokes on newer url types
from the spec. These tags are now supported both in appstream-util and
appstreamcli source code, except that appstreamcli had release 0.15.3,
available in Debian testing, whereas there were apparently no recent
appstream-glib/util release (and none since 2020). So for these various
reasons, let's go with the appstreamcli tool.
The only downside is that appstream package (where appstreamcli lives)
is not available on MSYS2, but since it's only an optional test tool for
XML files which should be common on all platforms, it's probably
acceptable.
For the build tool, we really don't need a recent GLib. Checking the few
function docs, GLib 2.2 is fine, which (looking at git logs) means any
version after 2002. At this point, it's nearly unneeded to add a minimum
required version, but let's be thorough.
Anyway really no need to block a build if we have an old build GLib,
which is completely enough, as long we have the recent host GLib.
GExiv2 0.14.0 was released last September. It has been on Debian Testing
since October. The MSYS2 repository for Windows also provides this
version now, and I have bumped the version used in gimp-macos-build. So
let's upgrade the requirement (for the dev branch only) so that we can
finally get rid of all the remaining annoying warnings relative to this
library.
Recent libtiff supports loading BigTiff automatically so we didn't have
anything to do there (as long as a recent libtiff was used). For
creating a BigTIFF though, we simply needed to add a "8" flag to
TIFFOpen/TIFFClientOpen when creating a new image (i.e. using "w8"
mode) as explained here in the "Implementation Strategy" section:
http://www.simplesystems.org/libtiff/BigTIFFProposal.html
What this commit does:
- Explicitly bump our libtiff requirement to version 4.0.0 or higher
(which is where BigTiff support appeared).
libtiff 4.0.0 was apparently released on 2011-12-22 and is available
on all current distributions, so it's probably not a problem.
- Switch to detect libtiff with a pkg-config test (added in libtiff
commit faf5f3eb before 4.0.0 release, so it's fine) instead of
function checks.
(Note: meson was already detecting for libtiff-4 with pkg-config,
which was obviously wrong since it should have mimicked autotools, but
well… then changes were minimal on meson)
- Add a new "bigtiff" boolean argument to the "file-tiff-save" PDB
procedure, FALSE by default. I set this as the first argument as I
figure that choosing the format you want is quite a major choice.
Unless I misunderstood something, since BigTIFF is really designed to
be an evolution of TIFF with a "minimum change strategy", i.e. mostly
using 64-bit instead of 32-bit offsets, everything which is possible
in TIFF will be in BigTIFF (and oppositely as well, except of course
having huge files) so there is no need to have 2 separate procedures.
- Adding this new argument to the GUI dialog as a checkbox.
- Tweak the load and export procedures' documentation strings to make
clear we support both TIFF and BigTIFF.
Note: interestingly there doesn't seem to be a separate mimetype for
BigTIFF so nothing to update on this side.
- Tweak the procedure labels too to mention BigTIFF. Since BigTIFF is
still a different format (though very closely resembling) from TIFF,
unlike some others which are just extensions embedded in a TIFF file
(like GeoTIFF we recently added), I figure it deserves to be
explicitly cited.
Ok that was a bit of a mess with the 4 build cases (combinations of
meson, autotools, vector and raster icons). I *think* this is now OK.
Basically we still need to build the colorsvg2png tool even when
installing vector icons, just for the purpose of the 2 icons
dialog-question and gimp-wilber-eek which we compile into GLib resources
from PNG images.
Also it looks like I completely forgot to add the subdir meson.build in
icons/Color/.
Build-time tool, which basically just rasterize SVG images (it doesn't
do anything special like gtk-encode-symbolic-svg which creates special
PNG for GTK to recolor them).
It looks like I had this prepared since 2018 according to file header,
but I just never finished doing it! :P
Basically now PNG icons of the Color icon themes do not need anymore to
be committed in the repository. They will be generated from the SVG
icons.
Also adding a missing icon from the 16px list (the Playground icon for
Preferences dialog was needed in 16x16 as well, yet missing).
JPEG XL plug-in always imported all JXL images
in 32-bit float precision in the past.
Now it also supports direct import in 8-bit
and 16-bit integer precision too.
Also called "feature" option in meson, so that by default it depends on
auto-detection of the gi-docgen hence won't break the configuration when
the tool is missing (the feature is simply disabled).
Also move the program check into the root meson file, which is anyway
much better to have a better visibility of features, otherwise we'd end
up just having tests everywhere in any possible random directory of the
repo.
Finally add a line in the summary of the configuration step, displaying
the docs generation being enabled or disabled.
Part of the fix for #5863, which is to depend on newer version of GExiv2
where I contributed new APIs using GError-s instead of GLib warnings for
metadata tag issues.
Now Debian testing packages GExiv2 0.14.0 (and MSYS2 has 0.12.3) so
let's bump the dependency for our dev branch.
gtk-doc has been slowly dying for the past few years; with gi-docgen we
have a nice successor.
This also makes sure the C documentation also uses the GIR file, which
in turn means faster build times (since all the C code doesn't have to
be parsed and recompiled again), and has a clear dependency graph.
See the [gi-docgen tutorial] for more info on how the system works.
[gi-docgen tutorial]: https://gnome.pages.gitlab.gnome.org/gi-docgen/tutorial.html
This is an official way to declare these plug-ins as now
unmaintained/deprecated.
Relevant plug-ins are:
1) help-browser (Displaying the docs): nowadays every desktop machine
has a browser. Let's just use whatever is the person's default
browser.
2) web-page (Web screenshot): it looks to me like every browser has this
feature by default now (I use it all the time in Firefox to get a
full-page screenshot, never in GIMP), even on mobile, I am told. It's
nice to have it in GIMP too, but not like absolutely necessary.
On the other hand:
1. It's a hell to build, with a lot of issues. We have regular issues on
our Flatpak-s. We don't manage to build it on our CI (only locally
apparently). Also it takes a crazy amount of time (like 90% of CI
build-time would be webkit).
2. From what I gather, new versions don't work on Windows anymore. Even
MSYS2 seems to have dropped the ball and don't try anymore.
Basically we would have a feature disparity from GIMP 3.0 (most
platform but Windows). We don't know when it will be resolved (if
ever) as it's been like this for years.
Now why we are keeping the code around instead of just removing
everything is that the topic tree in the help browser is useful and
comfortable to use. Ideally we should get some equivalent to help
browsing the help efficiently in the web docs as well (so basically
menus, web search and alike?). So I am told to keep the code around at
least for now to see if we can figure something out or improve the
situation.
Except for this point, we can consider the WebkitGTK plug-ins as
deprecated from GIMP 3.0 on.
On macOS at least, `xgettext` is not being correctly identified because
`AM_GLIB_GNU_GETTEXT` is blowing away `XGETTEXT` variable which then
messes up the version checking.
This moves that macro to after the version check.
GLib 2.68.0 was released on 2021-03-18 and has finally been added to
Debian testing (now that the release freeze is over!). So dependency
bumps are slowly going to happen again on the development branch.
Actually Debian testing has even 2.68.4, but it's a bit too recent and
2.68.0 is enough to get rid of some of the deprecation issues.
By default, when on "auto", the update check feature will be set
depending on the OS. In particular, on Windows and macOS, it will be ON,
because these are the 2 OSes which we distribute without an update
channel, hence where people used to have very outdated versions of GIMP.
On Linux, *BSD, and so on, distribution provide updates through package
repositories.
- Use aalib-config (available at least in the last releases of libaa,
1.4rc5 from 20 years ago!). Especially important as the basic
AC_CHECK_LIB() test does not work in my tests on Windows builds
because some more libs are needed.
- Make sure file-aa is also built if AA_LIBS environment variable is
explicitly set. Prevous code was not working in such case (file-aa was
not built even with AA_LIBS set).
Also ".sun" is a possible (and common) file name extension for Sun
Raster images, according to various sources and samples I found (these
samples with .sun extension also opened fine in GIMP, so it's not just a
subvariant which we may not handle or something of the sort). This one
is not so important though as we also register magic bytes for detection
(which is the proper way), but it can still be useful, mostly for
exporting (as we will direct to the SunRaster plug-in if someone tried
to export a file with .sun extension, since no other file format uses
this extension AFAICS).
There is no functional change, I just had a look at this plug-in while
handling !428 and realized this format was not present in the MimeType
list (which is used to generate the desktop file, in order to have
proper mime types, not detection based on extension only, unlike
Windows in !428).
pango_fc_font_lock_face() is deprecated since Pango 1.44.
This may hopefully also fix#5922 as I completely changed the code where
the CRITICAL happened. Yet I left g_return_val_if_fail() to check if the
Harfbuzz font and FreeType face variables are not NULL (because looking
at the code, it looks like these functions returning NULL actually means
there is a bug in the code).
Nevertheless if it turned out that there are non-bug cases where these
could return NULL (for instance a broken font file?), then probably we
should not use g_return_val_if_fail(), but instead address the data
issue in a nicer way.
Bumping harfbuzz dependency to 1.0.5 for hb_ft_font_set_funcs(). Without
configuring the Harfbuzz font with it, hb_ft_font_get_face() always
returns NULL.
Note that it looks like hb_ft_font_lock_face() would actually be better,
but this requires harfbuzz 2.6.5 from last April which is quite recent.
So let's just use the get_face() variant for now.
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>
For Python, Lua and Javascript, make the option boolean (with 'yes'
being the default). No need of a warning when not installing the
plug-ins as this would have been disabled explicitly anyway. When
installing the plug-ins, only make interpreter checks as precautionnary
verifications which don't actually change anything (except outputting
some warnings if interpreters are not found). Basically for these 3
bindings, the interpreters are only runtime dependencies anyway. So it
doesn't matter if they are not available at build time. In particular,
we get rid of the 'force' option.
Vala rules do not change as the vala compiler is indeed needed at build
time and current checks work correctly. I just add a "Vala plug-ins"
line in the summary message of the meson configuration, as it was
missing.
This is an extension containing a few demo plug-ins. This is good to
demonstrate the extension format. It will also allow to disable these
plug-ins (if at some point, one doesn't want to show these demo
plug-ins anymore).
And finally it deals with the fact that our plug-in code is stupid, as
it just tries to find the first executable with the same name (minus
extension) as the plug-in folder. This doesn't go well on Windows, where
the permission system is non-existent. So our code just ends up trying
to run the first file with a similar name in a plug-in folder. As the C
goat-exercise contains both an exe and the C source (and the system
probably returns files in alphabetic order), GIMP under Windows tries to
run the C source instead of the executable (this obviously doesn't go
well).
We could try to do more complex logics, like not aborting if the first
file run fails and try the next one in the plug-in folder. Or maybe just
rename the C file to another name. But any of these is just in the end
the proof that our plug-in discovery right now is just bogus. The
extension system is explicit, not based on randomly trying out files.
Plug-ins entry points are explicitly listed in the metadata manifest.
It's done, all Python plug-ins have been either ported to the new API +
Python 3, or they have been discarded (and moved to gimp-data-extras for
whoever wants to salvage them).
Let's get rid of the outdated pygimp directory (whose code has not been
built in the master branch for years now anyway)! Woohoo!
Jehan