(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
Since these are demos, for the sake of showing how the localization
works, let's localize the goat-exercises with a locally installed
catalog.
Note that actually use the gimp30-std-plug-ins catalog, simply I copy it
in the plug-in folder and rename it as org.gimp.extension.goat-exercises
domain.
As a consequence:
- The C plug-in does not need the INIT_I18N anymore, which was
specifically for the centrally installed catalog and cannot be used by
third-party plug-in developers (so it's not a good demo code).
- I now use GLib.dgettext() for Python instead of the gettext Python
module, because the later won't "catch" the catalog declared in
libgimp.
- The other Goat exercises are now localized correctly, unlike before.
- Just setting GETTEXT_PACKAGE is apparently enough for the Vala
plug-in.
- Lua is untested. Hopefully the code will work.
I added this call originally, mimicking the C plug-ins. Yet in Python,
this function is deprecated since Python 3.8 and removed in 3.10.
Looking closer in the docs, it looks like Python's gettext module works
differently.
While all the *gettext() functions return strings in the locale's
encoding in C, unless overriden by bind_textdomain_codeset() (therefore
we need this call, in order to have locale-independent string encoding),
this is not the case in Python, whose gettext() call is already
locale-independent. The gettext.bind_textdomain_codeset() function only
applies to the specific l*gettext() functions which are deprecated too.
Fixes the warning:
> goat-exercise-py3.py:37: DeprecationWarning: bind_textdomain_codeset() is deprecated
Problem appeared on mac and also on debian unstable. This is autotools
only as `--disable-since-check` is present
in meson.build.
Fix suggested by @nielsdg.
```
make[3]: Entering directory '/Users/distiller/.cache/jhbuild/build/gimp/extensions/goat-exercises'
CC goat-exercise-c.o
/Users/distiller/gtk/inst/bin/intltool-merge /Users/distiller/gtk/source/gimp/po-plug-ins org.gimp.extension.goat-exercises.metainfo.xml.in org.gimp.extension.goat-exercises.metainfo.xml -x -u -c ../../po-plug-ins/.intltool-merge-cache
VALAC goat_exercise_vala_vala.stamp
Generating and caching the translation database
CCLD goat-exercise-c
/Users/distiller/gtk/source/gimp/extensions/goat-exercises/goat-exercise-vala.vala:28.10-28.18: error: `Gimp.main' is not available in gimp-3.0 2.99.9. Use gimp-3.0 >= 3.0
return Gimp.main(typeof(Goat), args);
^^^^^^^^^
```
… drawable array instead of a single drawable.
Instead of expecting a single drawable, GimpImageProcedure's run()
function will now have an array of drawable as parameter.
As a consequence, all existing plug-ins are broken again. I am going to
fix them in the next commit so that this change can be easily reviewed
and examined if needed later.
I only fix the Vala demo plug-in now (or rather, I just use the first
layer in the array for now) because otherwise the build fails.
Make sure we regenerate the appdata file when po files are updated. It
should not be too much of a problem for release builds made from
scratch, but on incremental dev builds, the appdata was not regenerated
even when new translation got added.
… with N_().
Also fix the domain in self.set_translation_domain() call.
Actually I'll have to dig deeper in this function which apparently is
only used for menu entries. Yet it does feel quite redundant with
calling textdomain() and other gettext calls ourselves. Probably we can
make plug-in localization more straightforward.
Though GObject Introspection is normally not an option, the only case we
don't build it yet is when cross-compiling (as we haven't found the
right way to do it). So let's not build the Goat Exercise plug-in in
Vala in such case as we needed the introspected libgimp.
All our plug-ins are named "plug-in-*", and in particular our goat
exercise plug-ins are all named "plug-in-goat-exercise-*". Only the
Python 3 and Lua were named differently. This fixes the inconsistency.
Probably forgotten remnants from the C to Python port, as I copy-pasted
the C plug-in and converted each line of code to Python 3, one by one.
These semicolons are not breaking the plug-in, but that is still not
very "Python-style". Let's say it's valid, though useless in this case
and clearly not considered beautiful Python.
The metadata format being appdata, I simply use standard intltool
merging on the XML templates.
For Automake, I use a custom rule instead of INTLTOOL_XML_RULE because
the m4 macro hardcoded $(top_srcdir)/po as translation source directory
(yet we want to use po-plug-ins/ for these). Meson on the other side
already used a custom command.
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.
Anders Jonsson