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
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
Changes are mostly to the dir structures and build system for ScriptFu.
Some changes to the outer plugin source to call the library.
Why: so that other executables (future gimp-scheme-interpreter,
or a future separated script-fu-server) can exist in separate directories,
and share the library in memory (when built shared.)
Whether the library is built shared and installed on its own
(versus static and not installed)
is a compile time option (both automake LibTool and meson abstract it away)
The default is shared and installed, say as libgimp-scriptfu-3.0.so.
Installed alongside other shared libraries (e.g. wherever libgimp is installed)
to simplify packaging.
A preliminary refactoring which helps enable MR gimp!647
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!
Hugo Carvalho