GitLab

Add new PDB group "drawable_edit" which has all procedures from the
"edit" group which are not cut/copy/paste.

The new group's procedures don't have opacity, paint_mode
etc. arguments but take them from the context instead. Unlike the old
gimp-edit-fill, gimp-drawable-edit-fill now uses the context's opacity
and paint_mode.

The new gimp-drawable-edit-gradient-fill procedure uses even more
context properties which are also newly added with this commit
(gradient_color_space, gradient_repeat_mode, gradient_reverse).

And some cleanup in context.pdb.

This is still WIP, nothing in the edit group is depcreated yet.

The upper text will be centered on the top quarter of the bottom quarter
of the splash image, whereas the bottom text will be centered on the
bottom quarter of the bottom quarter of the splash (unless the splash is
too small, in which case the double of the layout pixel extents will be
used). Basically don't use absolute pixel values anymore for
positionning. This should all be done relatively since there are
nowadays all kind of display size (and positionning the text 6 pixels to
the bottom, as it was done, may be ok on low density displays, yet will
look ugly on high density screens).

Also write this down in the splash requirements in the release howto so
that splash designers are aware that the bottom quarter of their image
will have to be adapted for printing text.

Step 1: rename the icon to GIMP_ICON_TOOL_GRADIENT (gimp-tool-gradient)

... for plug-in debugging as well.

I create this file so that we can refer to it to know whether we can use
a OS-specific API, or if we want to know if we can safely bump a
dependency, etc.

Current splash is not right within these requirements. But that's all
right for this RC.
These requirements are meant to be followed from next release.

I completely forgot to rename the appstream file according to the new
ID. While doing so, I also make it a .in.in file, with initial
processing by the autotools. Indeed I need @GIMP_COMMAND@ to be replaced
by AC_CONFIG_FILES().
Finally I fix a badly closed XML tag (which reminds me I should always
test a commit, even when it's a simple non-C 1-liner change!).

Please don't forget to notify me too of an upcoming release. I need to
update the manifest (for stable releases at Flathub at least, since we
have not set the dev release process yet) and trigger a new build of our
flatpak.

- Fix language count.
- Update the commit message parsing for language name.
- Add more files to be counted as "documentation".

Trying to manually read commits to acknowledge translators, designers,
developers, etc. is just ridiculous. Let's try to have a script doing
the work for us.
You use it like this:
- GIMP 2.9.8 stats: devel-docs/release-stats.sh GIMP_2_9_6 GIMP_2_9_8
- GIMP 2.10 stats: devel-docs/release-stats.sh GIMP_2_8_0

...of official binaries

Add this point right after "Announce on the GNOME I18N mailing list."

Also remove the "wait for mirrors" thing at the end, in a subsection
of that point we say "as fast as possible" and that contradicts each
other.

Move the "properly chilled beverage" to the end where i belongs
(or perhaps it belongs where the build starts...)

This will be a neat reminder for some of the hidden environment
variables helpful to debug GIMP in some cases, as well as some other
tricks, which we often have to tell people or even which we forget (or
don't even know sometimes) ourselves.
This will be less annoying to just remember to check this file if we
forget the name of some environment variable than to try and grep the
git log or the code.
If someone adds another environment variable which changes some behavior
of the code, please add it here. Also if you know some other helpful
tricks, share with all. Thanks.

I've made the download and home page of gimp-web as generic as possible
so that one will just have to update GIMP_VERSIONS in order to release a
new version. In particular, no boring editing of hardcoded versions in
html pages anymore.
Also adding an item to update the authors page as well (which is
generated so it's just a matter of moving a file).

We are getting more and app/widgets/ is already too large.

Woohoo!  We can actually inject this into the gtk-doc thingy!

...instances of GIMP before a make distcheck

Mention it in release-howto.txt.

We should use "vector icons" instead. Thanks to nomis for raising the
question and ankh to confirm the proper English.

The GNU coding standards rules can be found in:
https://gcc.gnu.org/wiki/FormattingCodeForGCC
I added a few rules, like if the file has existing tabs, we want to show
them as 8 columns. Yet typing tabs automatically expands to 2 spaces.

I also added a rule to highlight (in red) trailing whitespaces, but also
tabs (everywhere, not only trailing) making them easy to spot.
This file can be easily sourced from vimrc for the whole GIMP tree, but
I advise against setting VIM to automatic discover a locale .vimrc,
which is possible but a high security risk since a third-party vimrc
could contain random shell commands.

This explains a little better why some systems (i.e. GNOME…) would show
no icons in menus whereas other (i.e. Linux Mint, Windows…) would show
them. GIMP_ICONS_LIKE_A_BOSS environment variable is a developer trick
to show icons in menus anyway to see how things render on such systems.

This reverts commit 2bfd0711.

Don't ask...