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
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.
See issue #1307.
There doesn't seem to be anything blocking us to publish to the
Microsoft Store, now that there is this new "traditional desktop
application" process allowing us to publish using our existing
installer. So GIMP 2.10.32 should normally be our first published
version there.
The urlmap file allows gi-docgen to generate links for namespaces that
are also generated by gi-docgen. For example, with this commit, a
reference to `GObject` will now be properly linked to the GObject
documentation.
This will work around such errors from the g-ir-doc build:
> devel-docs/g-ir-docs/pages/python/Gimp-3.0/Gimp.checks_get_colors.page:46: parser error : EntityRef: expecting ';'
> gimp_checks_get_colors (gimp_check_type (), &color1, &color2);
> ^
Similar to commit 7123b6c466, it cannot really be considered a proper
fix, barely a workaround for g-ir-doc-tool not even able to produce
valid XML. Here we have ampersands which it should have espaced into XML
entities.
Anyway this will do for now (until we just decide to drop the g-ir-docs
tools?).
In the original gimp-2-10 branch where this feature was originally
worked on, we had to keep gimp_checks_get_shades(). But on `master`
where we will reset and break API, let's get rid of this function which
should not be used anymore.
Why: MR !389 changed the signature of PDB procedures to return GStrv instead of (int, GimpStringArray)
This changes handling of results from a call to such a changed signature, in a Scheme script.
The symptom was a cryptic TinyScheme "Error: car: argument 1 must be : pair"
Most changed procedures are named like "-list".
I did a cursory grep to look for other instances.
Updated porting guide doc.
To work around the issue, I just wrote a stupid sed script. Of course,
it means that if we encounter again the issue on some other docs, we'll
have to update it. In other words, it's neither robust nor a proper
long-term fix. Just a temporary hack.
See: https://gitlab.gnome.org/GNOME/gobject-introspection/-/issues/425
Also fixing this issue, I encountered another bug, this time in meson,
which changes backslashes in slashes on 'command' arguments, in a
completely uninvited manner! The only workaround to this is apparently
to call an external script, which is ridiculous for such a basic stuff.
But well… here is why I implement this with a script, instead of
directly calling sed in the meson 'command'.
See: https://github.com/mesonbuild/meson/issues/1564
As I review and tweak various aspects of GIMP UI, I also write down
specifications for these subparts. Here is one for the locks behaviors.
We worked on these specifications with Aryeom and tried to make the most
useful and also somehow obvious logics for these locks, in particular
the cases when applied to layer groups which can have wider ranges of
meaning (on leaf items, it is much simpler). The various previous
commits are implemented based on these specifications.
XCF 17 includes the new visibility locks and the ability to add position
and alpha locks on layer groups.
I am going to push the various commits implementing these different
features together which is why we gather them as a single XCF version.
Also adding the CODING_STYLE.md. There is actually the question whether
we still want to track this docs files to package them in the tarballs.
It made sense 20 years ago when devs were working from tarballs, but
nowadays, devs are expected to work from git HEAD.
Anyway this fixes the CI.
- ps-menurc removed in GIMP 2.7.2 (i.e. stable 2.8.0) according to
NEWS.pre-2-8.
- in our main README, redirect now to devel-docs/README.md as entry
point for contributors.
- move HACKING to devel-docs/ and specialize it into a "how to build
from git and contributed" docs:
* Make it markdown.
* Remove some now obsolete or redundant recommendations (to be fair,
we can probably clean up the file a bit more, but we'll see).
* Add/improve relevant information.
* Make more obvious when you want to build from tarball or git.
* Just keep a single short paragraph about the coding style to
redirect people to the appropriate CODING_STYLE.md file.
* Don't recommend sending patches to the mailing list anymore.
- move CODING_STYLE.md to devel-docs/.
Makes more sense and I am trying to make the devel-docs more readable
(which includes less crowded, especially with scripts which are not
really docs).
I was wondering what this version file was for. After some git
archeology, turns out this was used for gtk-docs. Since we replaced
gtk-docs with gi-docgen in commit 92e80d12e8, this can be removed as
well.
Since I removed some files and forgot to change these rules. Though I
actually wonder if this still makes sense to distribute all these files
within the tarball anymore. It made sense in the way software was
distributed 20 years ago, but nowadays people who want to develop would
clone the git repo not get a tarball. We'll see.
Add some more text and links to existing documents.
I also remove 3 files which are now either outdated or whose contents is
also written (with more or less similar text) in other more up-to-date
files.
Add more links to other files after I reviewed they were still relevant.
The `gitlab-milestones.txt` in particular had to be updated because the
contents was outdated (though we still need to manage milestones, simply
now we are a bit more fine-grained).
Loosely based on the old structure.xml, except it was widely outdated.
So I removed or updated what was obsolete and added missing folders.
Obviously getting rid of the old `structure.xml` (now we have easier doc
generation through Gitlab).
Finally, I fix the table of contents and replaced the title with some
metadata-style stuff which Gitlab docs suggest (otherwise the document
title ends up in the table of contents, which is a bit silly).
This will be the root page for the developer documentation. Note that
there are other files in this directory (old `README` included) which
will need to be deleted but I don't do it just yet on purpose until I
checked them and integrate anything which could be of interest back into
the new documentation.
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.
gtk-doc has been slowly dying for the past few years; with gi-docgen we
have a nice successor.
This also makes sure the C documentation also uses the GIR file, which
in turn means faster build times (since all the C code doesn't have to
be parsed and recompiled again), and has a clear dependency graph.
See the [gi-docgen tutorial] for more info on how the system works.
[gi-docgen tutorial]: https://gnome.pages.gitlab.gnome.org/gi-docgen/tutorial.html
We now save and load layer and channel item sets. Only missing set types
are path ones, but the whole path item is just its own exception in the
XCF format, and adding support for it, while keeping compatibility with
older XCF seem like a small headache. I could do it, but I actually
wonder if it is worth it. Would people really need to store sets of
paths?
Also this commit finally gets rid of any remnant of the old item "link"
concept (I think), so we are getting close to merging the branch.
I cleaned many remaining places where the concept of linked item still
survived.
On loading an XCF file with linked items, we are now going to create a
named sets for the linked items, allowing people to easily select these
back if the relation was still needed.
We don't remove gimp_item_get_linked() yet and in particular, we don't
save stored items into XCF files. This will come in an upcoming change.
When running tests, the data are not meant to be necessarily installed.
Therefore icons won't be found when calling gimp_widgets_init().
Add some special-casing to find them relatively to the install
directory.
Over the last few years, we seem to have been in agreement that .ui
files are not so desirable anymore.
For plug-ins, they are completely deprecated in favor of our much nicer
dialog generation API from properties (the metadata plug-in(s) are the
only ones which still have .ui files but we plan to get rid of these
eventually).
For core code even, we also prefer to generate GUI when we can (as we do
for GEGL ops, for symmetries and other places).
GtkBuilder files actually make for more complicated code, imbricated in
both the C code and .ui files, more bug-prone too and we don't seem to
gain anything from the additional complexity.
So let's get rid of this dev guide.
- The trick to fetch automatically all MRs in read-only branches.
- How to temporarily checkout and push to a contributor's remote without
actually hard-naming their remote repo and polluting your local repo
with every new MR.
lloyd konneker