I'm actually syncing with a branch which I can't test right now because flathub
seem to have some breakage. For the nightly, let's just directly push as anyway
we can't test in Gitlab MRs either because of the non-master jobs timeout.
See: https://github.com/flathub/org.gimp.GIMP/pull/202
We should always keep the diff between these files to a minimum.
- Fix the markdown styling.
- Add commands on how to build GIMP from the local repository instead of a brand
new clone (otherwise I don't see how one could develop with flatpak). I knew
it were possible, but until today, I never tried to do this so I had to test
first.
- The cron file was from the very early flatpak experiments before Flathub came
into the picture, as well as the GNOME Nightly repository. Back then, we
wanted to set up our own nightlies or release repository through a cron.
- It is still interesting to keep some instructions for local builds of the
flatpak as some people want to use this for development (but all the part
about exporting to a repository, signing, etc. is now unneeded for such use
case). So I'm updating the howto to more current recommendations.
- `flatpak-howto.txt` renamed to `README.md`.
Only the libwmf patches are still different. Apparently we may have fixed the
same bugs in different way on both branches. We should look later in details to
see if some patches are better than the other.
It's probably unneeded as the 2.99 installers are transient and anything
installed by GIMP 2.99 won't be in stable 3.0 anymore. Still, it's nice not to
have any weird warnings even in dev releases.
Now that we bumped our meson requirement, meson is complaining about
several features now deprecated even in the minimum required meson
version:
s/meson.source_root/meson.project_source_root/ to fix:
> WARNING: Project targets '>=0.56.0' but uses feature deprecated since '0.56.0': meson.source_root. use meson.project_source_root() or meson.global_source_root() instead.
s/meson.build_root/meson.project_build_root/ to fix:
> WARNING: Project targets '>=0.56.0' but uses feature deprecated since '0.56.0': meson.build_root. use meson.project_build_root() or meson.global_build_root() instead.
Fixing using path() on xdg_email and python ExternalProgram variables:
> WARNING: Project targets '>=0.56.0' but uses feature deprecated since '0.55.0': ExternalProgram.path. use ExternalProgram.full_path() instead
s/get_pkgconfig_variable *(\([^)]*\))/get_variable(pkgconfig: \1)/ to
fix:
> WARNING: Project targets '>=0.56.0' but uses feature deprecated since '0.56.0': dependency.get_pkgconfig_variable. use dependency.get_variable(pkgconfig : ...) instead
… Windows installer localization.
There are kind of 2 separate bugs here:
- Direct i18n.gettext() to the proper data directory where to find the
ITS file. Otherwise `meson compile gimp30-windows-installer-pot` and
`meson compile gimp30-windows-installer-update-po` complained about
not knowing XML and falling back to C, which is obviously a problem:
> /usr/bin/xgettext: warning: file 'build/windows/installer/lang/setup.isl.xml.in' extension 'xml' is unknown; will try C
- Set gt:escapeRule to "no" in the ITS file, otherwise the XML entity is
kept as-is in the po file (i.e. "&" stays "&" inside the po
files), but it's considered as raw text when merged back to XML, i.e.
that the '&' is properly converted to a XML entity, so we end up with
a double escape "&".
Now the po file will have a '&' which will still be converted to XML
entity at merge time. This is actually most likely better than asking
translators to handle XML entities themselves (with the possibility to
make typos and break the XML entity).
See https://savannah.gnu.org/bugs/?58643
The Hungarian language file for the Windows installer was recently moved
from unofficial to the officially supported languages. However, a new
release including Hungarian by default is not available yet. This causes
our CI to fail because it can't find Hungarian in unofficial.
We change our ci script to download Hungarian from the correct location
for official languages, and adapt gimp3264.iss to reflect the correct
location.
The language files provided by the InnoSetup project (either the main
ones or the "Unofficial" ones, i.e. less maintained ones) at least
provides the name of the language, possibly in English, ideally
self-localized in its own language.
Unfortunately Kabyle didn't have any language file so we were using the
Default one, which ended up showing the lang as a duplicate (and very
wrong) "English".
With this commit, I add code to provide our own very basic base language
file, which would at least contain the language name. There is also a
concept of language ID to be verified in Windows-provided list.
Unfortunately it doesn't have any (actually it was id-ed 0x1000 like
many other languages, which looked therefore to be the code for an
unsupported lang). InnoSetup docs tells us to leave 0 then. We can add
the ability to set a specific code later in the template if we add other
un-provided languages and if they have their own lang id.
With this base infrastructure, we should be able to better support more
languages.
Unfortunately the weird encoding of a string to bytes to get the UTF-8
BOM worked on my local machine, but not on the Windows CI. I'm not going
to fight it and fallback to a shell script.
I am guessing it should work fine on all platform since we use basically
the same sed call in build/windows/gitlab-ci/installer-gimp-msys2.sh
already.
Inno-Setup absolutely requires it to recognize UTF-8 translation files.
This should hopefully be the final fix to #8338.
Note that this fix is full of workaround for meson bugs or limitations.
While it was a one-liner in autotools, added to the existing rule, here
I have to add an additional (non-relevant) target rule, then uglily work
around 2 bugs:
https://github.com/mesonbuild/meson/issues/1564https://github.com/mesonbuild/meson/issues/7696
I can't say I'm so happy about the resulting change, even though it
seems to work. If anyone can propose a nicer build rule, it would be
welcome.
Whenever we have an element without translation, we try to use the value
without a `xml:lang` attribute. That selector was wrong though, which
leads to https://gitlab.gnome.org/GNOME/gimp/-/issues/8338, which should
now be fixed.
Why:
1) users can install .scm scripts to plug-ins dir
2) Crashing scripts do not crash extension-script-fu
Scripts (.scm files) have a shebang and are executable
and in a same-named subdir of plugin dir.
Interpreter/scripts create PDB procs of type PLUGIN unlike extension-script-fu
which creates PDB procs of type TEMPORARY, owned by extension-script-fu.
Unlike other interpreters, the interpreter is-a plugin outright,
not by virtue of the script subclassing GimpPlugin and using GI.
More details in /plug-ins/script-fu/interpreter/README
(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
This will allow to use the official Windows installer directly in the
Windows Store, as per the new proposed workflow by Microsoft.
Nevertheless our GIMP for Windows has a built-in update check which
would check if a new version exist and warn people (advising them to go
on the website and download the new installer to update). We obviously
don't want this on the Windows Store which has its own update channel.
It would be confusing.
Therefore I added a feature to disable the built-in update check (not
even showing in Preferences) by tweaking a single package variable. The
installer now comes with new option /DISABLECHECKUPDATE=true which will
add said variable.
JSON does not support comments and their support in Flatpak is possible
through use of json-glib[0]. This is problematic in fully utilizing
flatpak-external-data-checker because its JSON writer does not respect
existing comments. To solve this, make use of Fltpak's specific
behaviour where a "//" key is explicitely ignored while parsing[1].
[0] flatpak/flatpak-builder#363 (comment)
[1] 0e98b7ae19/src/builder-utils.c (L1250)
OpenEXR and mypaint-brushes offer next major versions. GIMP is probably
not ready for the changes in OpenEXR and mypaint-brushes are not yet
finalized. Put their versions under constraints so that automatic PR
creation for dependency bumps can be enabled.
It looks like the gi-docgen build is broken on Windows (though the CI
does show neither stdout nor stderr output, just a failure without
message). This should be fixed, but it's not necessary for the installer
at least.
Note: on autotools, the gi-docgen step works fine on Windows.
We didn't need to do this on the autotools build, simply because the
configure step is much more elaborated there, and was checking for the
header file as well as well as a working mng_create() API. But since
libmng was broken, the test failed, so we didn't need to disable it.
By the way, we should check when the `.pc` file was added, because if it
was after the required version, then the meson test is very wrong. It
should not have been different from the autotools file.
The meson build still has a bunch of issues and build bugs compared to
the autotools build, nevertheless the last blocker issue was dealt with
a few days ago (PDB source generation).
Moreover since the meson build on Windows especially makes such dramatic
difference, in terms of build speed, this is a big improvement for
Windows contributor's comfort, and as such is one less barrier of entry.
Anyway I believe that most Windows developers build GIMP with meson now
so sticking on autotools on this platform is just counter-productive.
This is why it was decided to now make meson the recommended build
system on Windows, as a further step toward a move to meson. It is still
not the recommended build system on the other platforms yet.
The --debug option so far would only output debug info. I want both the
run to actually occur and the debug to be printed, at least in some
cases. So I make this a choice option with 3 variants (no debug, debug
only and run + debug).
