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.
Though the Color and Symbolic icon themes will have a different build
process and naming scheme for their icons, the base list is meant to be
the same by maintenance principle. So I am moving out the lists to the
icons/ directory's meson file.
Bumping meson requirement to 0.53.0 because I need to ability to use a
variable as dictionary key (not only string literals), which appeared in
this version. Meson 0.53.0 was released 2020-01-07 and seem to be used
in any stable distribution released since 2020. In any case, it seems
widespread enough to bump it now for our dev branch.
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).
I realize that this module is available since meson 0.53.0 though our
current requirement is meson 0.50.0.
Note sure why meson was not popping any warning (normally it does when
we use a feature younger than the minimum requirement; but maybe this
doesn't work for modules).
Anyway this does the same thing without the 'fs' module, and maybe even
better (we know which icons should be converted or used from source, no
need to add any test logics here).
The whole logics of creating specially prepared PNG images for vector
icons (with gtk-encode-symbolic-svg) was absent. This option was
basically completely broken, yet we now know that we need the ability to
install PNG alternatives for the icons (see #6821).
This is a continuation of previous commit which is straightening a bit
our whole icon theme builds. Note though that more needs to be done
because I definitely still see room for more mess and far too much
duplication.
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.
Not sure why this was set as optional in the meson build, as it was
already mandatory in the autotools build back then (and for as long as I
remember).
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.
This is untested on my side, because the bug only happens on native
builds with meson (our CI has cross-builds with meson and native builds
with autotools and I only do cross-builds locally) but I think/hope it
will work.
Basically we were using .full_path() because these rc files were also
used as input of some configure_file() calls which doesn't like custom
target objects as input (it wants strings or file objects). Yet a bug
in meson didn't like the colon used in native Windows full paths ('C:'
and such) when used in windows.compile_resources(). This has been fixed
by Luca Bacci in: https://github.com/mesonbuild/meson/pull/9368
Yet we just cannot depend on very early meson (or worse dev meson code).
On the other hand, if the input is a custom_tgt object, it uses the
object ID which we give as first parameter of custom_target() so we know
it's appropriately named without colons (such as 'gimp_plugins_rc').
Thus we should not bump into this issue again.
For the few usage in configure_file(), I just add a .full_path() only
when needed at call time.
Last but not least, I replace the bogus `meson --version` call by a
`python3 -c 'exit()'` as advised by Eli Schwartz:
2afa019c70 (note_1284951)
The reason is that it is apparently possible (or will be when some
reimplementation of meson will be done) that the `meson` executable
itself does not exist. On the other hand, `python3` should always be
there, as a mandatory dependency of the build tool.
In order to use an appropriate `python3`, I made the
pythonmod.find_installation() check required in our build (which should
not be a problem since it's a meson requirement as well), even when the
-Dpython option is false (this one depends on other requirements too
anyway, such as version and pygobject). This way I can call this meson
variable of discovered python in my bogus call, instead of calling a
(potentially different) python from PATH environment.
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.
As discussed in !455: remove duplicate testing, testing header and
testing the library are a same test in one (for instance we don't want
to get into weird cases where the lib is found but not the header; this
updated test takes such inconsistencies into account). Also it's better
to have all dependency tests together in the root meson file.
Finally adding some comments to make this all more understandable for
anyone looking at this in the future.
The authors.xml validation was also not run. This is nearly the last of
getting rid of run_target(). There is still the desktop file validation
but it doesn't have any output argument. We'll see how we update this
last one.
The only other usages of run_target() are proper usage (creating
'install-*' targets).
Per discussion on !262 and in particular Ell comments, the contributed
patch was right but the comment was not. It is not just about
g-ir-scanner and failing build. The build can still be successful yet
the built GIMP would crash when run on a CPU not supporting all the
extensions.
Don't enable conditionally based on the buildtype.
Further, don't use `add_project_arguments()` to enable the instructions:
this will lead to crashes within g-ir-scanner, which can't properly
parse these instructions.
https://gitlab.gnome.org/GNOME/gimp/-/issues/5053
To this day, the windows-installer option only creates the language
files for the installer. There is just no reason to forbid building them
(hence testing the option works) on non-Windows platforms. In autotools,
it already works fine on all platforms.
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).
Similar to the --enable-g-ir-doc option I just added on autotools. Also
separate this option from gtk-doc as it is unrelated (not everything
under devel-docs is related to gtk-doc!).
Based on the proposed process proposed by Akkana Peck. Thanks Akk!
For now, it's only in the meson build, which is fairly terrible to use
as soon as we do custom build rules. Here are the list of issues:
- meson does not allow building in subdir (issue 2320 on meson tracker).
Sure I could make several subdirs with meson in them. But here the
future goal would be to be able to generate docs for other
introspected languages, and maybe also other output formats (epub or
whatnot). For this, since these are basically the same commands which
are used, the best practice would be to have loops generating one
target per language/format combination, reusing code rather than ugly
copy-pasting in subdirectories' meson files).
- custom_target() requires the output parameter to be the complete list
of generated files. But we have more than a thousand of them. It's not
practical. Maybe we could try to find a way to generate the list from
the contents of the .def files which are already exhaustive and exact.
- Install also requires the output list to be complete.
- I temporarily have these docs not generated by default (because the
gtk-doc option is already crazy slow as it is, making meson near
unusable for development if it's enabled). If you want to generate the
docs, the commands are as following (yeah I don't understand what the
target names are for since meson does not actually create targets with
these names, so we have to use fake output names instead):
> ninja devel-docs/g-ir-docs/Gimp-python-html
> ninja devel-docs/g-ir-docs/GimpUi-python-html
Note that profile support also affect AVIF but since AVIF support came
anyway after libheif 1.4.0 (which is when color profile support
appeared), there is no way to differentiate there.
Thanks to Darix for noting the miss.
See: https://gitlab.gnome.org/GNOME/gimp/-/issues/5787#note_938976
libheif pc files provides variables which are actually older than our
minimum libheif requirement (so it's usable generically) to determinate
if libheif was built for HEIC/AVIF support. This is quite useful as we
had our share of annoyance with missing support of some encoder/decoder
even when libheif requirement was alright.
Also adding image/avif (if relevant decoder is present) to list of
supported mimetypes.
Jehan