(1) On recent meson versions, it fixes this error:
> extensions/goat-exercises/meson.build:108:0: ERROR: i18n.merge_file keyword argument 'output' was of type array[str] but should have been str
As docs explains, 'output' only accepts one item in i18n.merge_file().
This bug also happens on older meson (but there the reported error is a
lot less useful as it doesn't mention local meson build code).
(2) `setup.isl.xml` is a temporary intermediary file used to create the
Windows installer. It must not be installed.
(3) `gimp30-windows-installer.mo` itself is only used to create
`setup.isl.xml`. It must not be installed as well.
(4) gimp-tips.(its|loc) files (same for gimp-tags ones) should not be
installed. They are only temporary data.
(5) Fix environment variable: s/GETTEXT_DATA_DIRS/GETTEXTDATADIRS/
Fixes:
> /usr/bin/msgfmt: cannot locate ITS rules for ../../../data/tips/gimp-tips.xml.in
(6) Fix various bugs in the *.setup.isl files creation in autotools
build (typo, wrong files used, order of options in `xsltproc`
apparently meaningful, and so on. I guess the autotools build was
not as well tested as the meson one :P).
(7) Fixing the unit test verifying language lists consistency.
(8) `setup.isl.xml.in` must be added to the distribution.
intltool has long been dead upstream. Let's not poke the dead corpse,
please.
This commit is quite large, but that's mostly since trying to support a
hybrid of both gettext and intltool with both Meson and Autotools was
really hard, so I stopped trying.
Due to gettext relying on quite some things being at the exactly right
place in the autotools build (like `ABOUT-NLS` and `config.rpath`) we
really needed to cleanup the `autogen.sh` to only call `aclocal` and
`autoreconf`. No more strange magic; I tried to do it without changing
too much in the file, and things just broke. If people want to do
something more custom, they can just change the script directly. This
change also uncovered some problems in our `configure.ac`, like using
deprecated macros.
The following major changes happened:
* meson: Changed `custom_target()` to `i18n.merge_file()` for all
supported file types
* Added `.its` and `.loc` files for the GIMP-specific XML formats, so
that gettext understands them
* For the `.isl` (Window installer stuff) file, there's no easy way to
do this in gettext, so instead we start from an XML file (again with
its own ITS rules etc), translate that with gettext, and then use
`xsltproc` with a bit of magic to output the .isl file for each
language
* the `po*/Makefile.in.in` files are migrated to `Makevars` files,
which gettext natively understands.
Fixes: https://gitlab.gnome.org/GNOME/gimp/-/issues/8028
Instead of having a single "Planar RGB" format in the list, let's add
this as a generic parameter. Not only does it make the feature
symmetrical to "file-raw-save", but it also bring the ability to all
multi-channel formats. So now, we can load RGB, RGBA, GRAYA, whatever
the bit depth and the data type stored in planar configuration.
… "endianness".
The list of formats being a single list was actually interesting
UI-wise, in the case where you aren't sure of the data layout (but say
you know at least the dimensions), you can easily and quickly scroll
through the combo list (e.g. with keyboard arrows).
But when you knew your data, it was a pain to use. And as a general
rule, so many choices in a list is not the best interface.
I broke the option into 3 options, and in particular adding a
"data-type" which would tell what type of values are stored (integer,
signed or unsigned, or float) and an "endianness" to tell the byte
order. The idea behind is that these don't change the layout of
components and their size. It means that we can still do the
scrolling-randomly-through-formats trick in some fashion because we
might likely be able to detect shapes when we get at the right layout,
even though we are still set to use the wrong data type and/or the wrong
endianness.
… loading support as raw data.
Barely any new code (and actually a bit chunk of removed code) as we are
using generic code paths now.
"file-raw-load" procedure now supports all possible formats which can be
exported by the "file-raw-save" procedure (and more).
Only thing remaining now is looking how to simplify the GUI because this
overlong Pixel format combo box is quite a pain.
The "revision" field in the json file is supposed to be int. But I just
realized that it was set as string a few times, e.g. in Windows
installer revision 1 of GIMP 2.10.32. As a consequence, the revision 0
build was not able to detect the new revision.
I have now fixed the data in gimp-web repo (commit e7690e36), yet just
in case this ever happens again, I make the parsing code more robust by
accepting string revision, then properly converted to int.
Since we can now export these, let's add import support.
I copied the function halfp2singles() from babl code (as-is, without
formatting according to our coding style on purpose as we might just
want to switch this again later on).
I add the Little and Big Endian variants, but not the signed one for
now, because I am unsure how common it is. We have signed grayscale
variants, but it might be specific use cases there.
While adding these new loading support, I factorize the code when
possible by making all full-bytes RGB/Grayscale code more generic and
using the same code paths. In particular, raw_load_gray_8_plus() is now
removed as raw_load_standard() will handle all full-bytes use cases
where the input and output formats have the same components in same
order.
Also RAW_RGB and RAW_RGBA are renamed to RAW_RGB_8BPP and RAW_RGBA_8BPP
respectively.
We regularly have package issues which are discovered soon after
release. Let's try a new step in the release process where we would
build packages in advance just for testing.
- rename raw_load_gray16() into raw_load_gray_8_plus() and make it
handle all full-byte grayscale data. Move 8-bit grayscale data to use
this function as well.
- As a consequence of the previous point, we can also easily support
32-bit grayscale images (little/big endian, signed/unsigned).
- Make preview image code more generic as well.
Also I improve a bit code from previous commit in raw_load_rgb565(). The
allocated and read code didn't need to be the size of the full line
stride. Just the tile rectangle width was enough.
Rather than allocating 2 huge data buffers of the whole image size (one
in RGB565 and one in RGB-u8), just iterate through the file only
creating one single small temporary data buffer for single input line in
tiles returned by the iterator. This will be much better,
memory-efficiency wise.
Create new plugin file script-fu-server-plugin.c
with code extracted from script-fu.c, which is an omnibus plugin
implementing PDB proc extension-script-fu and other PDB procs.
Why:
1. extension-script-fu is smaller and doesn't doesn't link to socket libraries.
(GIMP always starts extension-script-fu and it stays running.)
2. packagers/admins can omit script-fu-server executable from an installation,
if they think letting users serve net ports is not secure.
3. crashing script-fu-server does not crash extension-script-fu,
which requires restart of GIMP
The changes are mostly a simple refactor, extracting code.
No functional change apparent to users.
Low risk of introduced bugs.
Extremely few users use script-fu-server anyway.
Added some logging.
While at it, use G_DECLARE_FINAL_TYPE
Should have paid more attention. I left 2 warnings in the file:
> plug-ins/common/file-raw-data.c:1949:22: warning: variable ‘procedure’ set but not used [-Wunused-but-set-variable]
> plug-ins/common/file-raw-data.c:1970:48: warning: ‘bpp’ may be used uninitialized in this function [-Wmaybe-uninitialized]
Niels De Graef