[gimp-web/2_99_8_RN] Review of the upcoming 2.99.8 release notes

[Alexandre Prokoudine <aprokoudine src gnome org>]

commit ebb8c86e93470771e9acab791f5c6ff8ec7fe825
Author: Alexandre Prokoudine <alexandre prokoudine gmail com>
Date:   Mon Oct 18 02:02:03 2021 +0300

    Review of the upcoming 2.99.8 release notes

 .../2021/2021-10_GIMP-2.99.8_Released/index.md     | 325 ++++++++++-----------
 1 file changed, 150 insertions(+), 175 deletions(-)
---
diff --git a/content/news/2021/2021-10_GIMP-2.99.8_Released/index.md 
b/content/news/2021/2021-10_GIMP-2.99.8_Released/index.md
index f47f9adb..75c74e57 100644
--- a/content/news/2021/2021-10_GIMP-2.99.8_Released/index.md
+++ b/content/news/2021/2021-10_GIMP-2.99.8_Released/index.md
@@ -24,8 +24,7 @@ To get a more complete list of changes, you should refer to the
 file or look at the [commit
 history](https://gitlab.gnome.org/GNOME/gimp/-/commits/master).
 
-# Core changes
-## Clone-type tools updated
+## Clone-type tools now work on multiple layers
 
 The `Clone`, `Heal` and `Perspective Clone` tools now work when multiple
 layers are selected. There are 2 new modes in particular:
@@ -33,121 +32,109 @@ layers are selected. There are 2 new modes in particular:
 * When *sourcing* from multiple selected drawables then *cloning* into a
   single drawable, the pixel source is the composited render of source
   layers. This is similar to "Sample Merged", except that it is limited
-  to a list of drawables and you don't have to hide layers which you
+  to a list of drawables and you don't have to hide the layers that you
   don't want to source from.
 
-* When *cloning* while multiple drawables are being selected, each
+* When *cloning* while multiple drawables are selected, each
   drawable clones from itself to itself, i.e. every drawable is both its
   source and target (the layers selected when *sourcing* do not matter
   in this case). This can be very useful in particular when you need to
   heal several layers exactly the same way, for instance when working on
   textures and various texture mappings.
 
-## Wayland (and a bit of macOS)
+## Selection cue now works properly on Wayland and macOS
 
 Windows drawing logics evolved in recent compositing window managers. In
 particular, the drawing of image selection (marching ants 🐜
-representing your selection boundary) broke on Wayland (and macOS since
-BigSur release). The selection tools were still perfectly working but
-the outlines were simply not visible on the canvas anymore.
+representing your selection boundary) broke on Wayland, as well as on
+macOS since _Big Sur_ release). The selection tools were still perfectly working but the outlines were 
simply not visible on the canvas anymore.
 
 We fixed this by reimplementing part of how selections were being drawn
-over the image. It was targetted for Wayland, but our recent macOS
-contributor (see below in [macOS package](#macos) section) confirmed it
-also fixes the issue for BigSur and above. Now the next step is to
-backport this fix to the stable branch (only for macOS since the GTK2
-stable version works with XWayland, hence doesn't exhibit the bug).
-
-An additional change, specifically to our Flatpak is that we will use
-the new "fallback-x11" permission instead of "x11" to prevent
-unnecessary X11 access while in Wayland, hence improving security step
-by step.
-
-Finally some people reported huge memory leaks of GIMP under Wayland
+over the image. We aimed to only fix this for Wayland, but our recent
+macOS contributor (see below in [macOS package](#macos) section) confirmed
+it also fixes the issue for Big Sur and newer. Now the next step is to
+backport this fix to the stable branch (only for macOS, since the stable
+GTK2 version uses XWayland and thus doesn't exhibit the bug).
+
+There have been two more Wayland-specific changes. For our Flatpak builds,
+we will now use the new "fallback-x11" permission instead of "x11"
+to prevent unnecessary X11 access while in Wayland, hence improving
+security step by step.
+
+Finally, some people reported huge memory leaks of GIMP under Wayland
 only (it was fine on X11). We didn't do much so we can't take any credit
 for this, but this seems to have been fixed, probably by a fix in a
 dependency with Wayland-specific code.
 
-## Windows Ink support (Windows only)
+## Wider coverage on input devices thanks to Windows Ink support
 
-Preferences now allows to select the input device API on Windows (Wintab
-or Windows Ink), as Windows Pointer Input Stack (Windows Ink) support
-was added recently in GTK3. This is a huge milestone since more graphics
-tablet or touch devices come with Ink support as a default whereas the
-legacy Wintab interface requires specific drivers.
+Windows Pointer Input Stack (Windows Ink) support was recently added
+to GTK3, so we made it available in GIMP and added a new option in the
+_Preferences_ dialog to switch between Wintab (older API) and Windows Ink.
+You cam find this option on the _Input Devices_ page of the dialog.
 
-This is even more the case with Windows 8 and over, for which most
-tablets should work out-of-the-box with Windows Ink.
+This is a huge milestone since more graphics tablet or touch devices come
+with Ink support as a default whereas the legacy Wintab interface requires specific drivers.
 
-Note that it might be backported to the GIMP 2.10 series. To be
-continued…
+This is even more the case with Windows 8 and newer, for which most
+tablets should work out-of-the-box with Windows Ink.
 
 ## Canvas-focus by toolbox clicking
 
-Clicking anywhere on the toolbox or on Wilber's drop area now actively
-focuses the canvas (similarly to the `Esc` shortcut). This will allow to
-more efficiently work on canvas with shortcuts.
+Clicking anywhere on the toolbox or on Wilber's drop area now returns
+the focus to the canvas (similarly to the `Esc` shortcut). This allows
+to work on canvas with shortcuts more efficiently.
 
 For instance, you could pan directly with the `Space bar` without having
-to click on canvas (hence activate a tool) when your keyboard focus was
-previously on some text widget, by clicking anywhere on toolbox (buttons
-and dead area alike) first.
+to click on canvas (hence activating a tool) when your keyboard focus was
+previously on some text input widget, by clicking anywhere on toolbox
+(buttons and dead area alike) first.
 
 ## Dropping thumbnail icon
 
-After years of discussions and reports by people, we dropped the
-Thumbnail icon feature: when images were opened, the application icon
-used to be a composition of the active image and the application icon
-(Wilber). For many people, this changing icon was confusing and hard to
-distinguish when searching for GIMP among other software's windows.
-
-Moreover this feature was actually working on less and less platforms
-because of recent OS and desktop rules. So depending on your
-configuration, you were already only seeing the Wilber icon, or worse
-this icon feature could be actively working against your desktop. This
-is why we decided it was better to just drop the feature rather than
-making it an option, because we cannot fight forever against changes of
-paradigms from the various desktop and operating systems.
+After years of discussions and bug reports, we dropped the thumbnail icon 
+feature. Previously, when images were opened, the application icon in the taskbar would combine a preview of 
the active image and the actual
+application icon (Wilber). The icon would then change whenever the active
+image changed. For many people, this complicated locating GIMP's window
+among windows of other running applications.
 
-## Leak-chasing
+Moreover, due to recent changes in desktop environments' behavior, this 
+feature was actually working on less and less platforms. So depending
+on your OS and desktop environment, it either didn't work at all or actively worked against you. This is why 
we decided to do away with it.
 
-Some contributors, such as Andrzej Hunt and Massimo Valentini, seem to
-have decided to chase small memory leaks with code analyzers, which is a
-very nice way to spend your downtime. We recommend! 👍
+## Improved file formats support: JPEG-XL, PSD/PSB, and more
 
-# File formats
-## JPEG XL
+**JPEG-XL** is now optionally supported thanks to Daniel Novomeskỳ
+who also previously contributed HEIC/AVIF support.
 
-JPEG XL is now optionally supported through the awesome work of Daniel
-Novomeskỳ, who also did a lot for our HEIC/AVIF support.
+GIMP can now load and export JPEG-XL files (`.jxl`) in grayscale and
+RGB, with color profiles support. Our exporting code also provides
+a "*lossless*" option and several "*speed*" encoding values.
 
-GIMP can now load and export JPEX XL files (`.jxl`) in grayscale and
-RGB, with color profile support. Our export also provides a "*lossless*"
-option and several "*speed*" encoding values.
+This plug-in is different from the [third-party 
plug-in](https://github.com/libjxl/libjxl/tree/main/plugins/gimp) that is part of the `libjxl` library
+that we use too. It supports GIMP 3 plugin API, reads greyscale images
+as greyscale, is written in C rather than C++, and exposes several presets
+for speed/quality tradeoff. We also do not yet expose features that could be
+considered experimental. If you are interested in JPEG-XL support
+for GIMP 2.10.x, please use the plug-in from `libjxl`.
 
-By the way, for anyone interested into this format and want it on the
-stable GIMP 2.10 series, a [third-party plug-in is
-available](https://github.com/libjxl/libjxl/tree/main/plugins/gimp),
-developed by the developers of `libjxl` themselves (the library we use
-for our own plug-in).
-
-## PSD and PSB
-
-GIMP now supports bigger-than-4GiB PSD files and loading up to 99
+We also improved support for Adobe Photoshop project files. GIMP now
+supports larger-than-4GiB **PSD** files and loading up to 99
 channels (specs say that 56 is the max but some sample PSD files have
 more channels).
 
-Furthermore the PSB file format is now supported for loading.
+Additionally, now you can also load PSB files which are essentially PSD files
+with support for width and height of up to 300,000 pixels.
 
-## Other formats and plug-ins
+There have been even more changes to file formats support:
 
 * 16-bit SGI images are now supported (until now, they were loaded as
   8-bit).
 * The WebP plug-in was ported to the `GimpSaveProcedureDialog` <abbr
   title="Application Programming Interface">API</abbr>.
-* Scriptfu now handles `GFile` and `GimpObjectArray` types.
+* Script-Fu now handles `GFile` and `GimpObjectArray` types.
 
-# Plug-in development
+## Plug-in development
 
 Our <abbr title="Application Programming Interface">API</abbr> for
 plug-in developers got the following improvements:
@@ -160,20 +147,22 @@ plug-in developers got the following improvements:
   to their own `GtkSizeGroup` for better aligned generated dialog, yet
   only within their own level of widgets.
 
-# Development and Continuous Integration
-## Windows
-### Development installer "nightlies"
+## Memory leak fixes
+
+Several contributors including Andrzej Hunt and Massimo Valentini started
+chasing small memory leaks with code analyzers, which is a very nice way
+to spend your downtime. We recommend! 👍
 
-A huge improvements is that we wrote rules so that our Continuous
-Integration platform creates installers.
+## Continuous integration changes
+### Windows
+#### Development installer "nightlies"
 
-This is very useful for having users test regularly code so we set up a
-weekly installer creation (the full process takes about 2 hours, so we
-didn't want to trigger it too often).
+We wrote rules for the continuous integration platform to create installers.
+This is very useful for users who want to test new unreleased features
+and bug fixes. Installers are being created once a week because the full process takes ca. 2 hours and we 
didn't want to trigger it too often.
 
-If you want to test the last "nightly" (common name used to call these
-development builds, even when they end up not being on a daily
-schedule), you can:
+If you want to test the latest installer for Windows, here is how you
+can do it:
 
 1. Go to GIMP's [scheduled pipelines
    listing](https://gitlab.gnome.org/GNOME/gimp/-/pipeline_schedules)
@@ -188,136 +177,122 @@ This procedure or any updated version of it is available in the
 "*Automatic development builds*" section of the [download
 page](https://www.gimp.org/downloads/devel/).
 
-⚠️ Be warned that a nightly being purely automated builds, without any
-human verification and happening at a semi-random time during the
-development process, you may end up with very broken software at times
-(even though we try to never leave the repository in a dire state).
-It is even less safe than development releases. People are welcome to
-test our nightlies to help us with feedbacks and bug reports, but you
-should not expect these builds to be considered as anything finale or
-even usable. ☢️
+⚠️ Be warned that a weekly installer is a purely automated build,
+there is no human verification. It is happening at a semi-random time
+during the development process, you may end up with very broken software
+at times, even though we try to never leave the repository in a dire
+state. It is even less safe than development releases. We are grateful
+for feedback and bug reports. Just please don't expect these builds
+to be rock-solid or even usable. ☢️
 
-### Release installer automated
+#### Automated release installers
 
-Additionally to the nightly installers, our Continuous Integration
+Additionally to the weekly installers, our continuous integration
 platform will now also generate the installer when a new release is
-tagged. The only part of the installer creation process which is not
-automated is the file digital signature.
-
-Digital signing will be done manually by our long-term Windows installer
-maintainer, Jernej Simončič, who will download and verify thoroughly the
-installer before signing it. This way, you should get the best of the
-reactivity allowed by automation with human-verified software.
+tagged. This should allow for much faster installer releases, within
+hours instead of days in the former fully manual process.
 
-This should allow much faster installer releases, within hours instead
-of days in former fully manual process.
+The only part of the installer creation process that is not automated
+is applying the digital signature. Digital signing will be done manually
+by our long-time Windows installer maintainer, Jernej Simončič. He will
+download and verify thoroughly the installer before signing it. So you
+are getting the best of both worlds: automation builds and human-verified
+software.
 
 *Note: this semi-automated release process is only for our development
 branch; it will be used in the stable branch when we will release GIMP
 3.0.*
 
-### Consistency of the installer scripts
+#### Consistency of the installer scripts
 
-Additionally to the automation of Windows installer, we added some
-additional tests for verifying installer script consistency. In
-particular, translations are handled by the [GNOME translator
-teams](https://l10n.gnome.org/module/gimp/) and we sometimes get new
-languages which are not properly listed by the installer (by the past,
-we announced some new installer languages which could not be found in
-the released installer! 😅).
+We also added some additional tests for verifying installer script consistency. In particular, translations 
are handled by the
+[GNOME translator teams](https://l10n.gnome.org/module/gimp/), and we
+sometimes get translations into a new language that is not yet properly
+listed by the installer. A few times in the past, we did announce a new
+installer language which users then could not find in the actual
+released installer! 😅).
 
-Our Continuous Integration will now warn us when such a case happen
-again, so that none's work is wasted and all new translations are
-properly used by the installer.
+Our continuous integration platform will now warn us when such a case
+happens again, so that noone's work would be wasted and all new
+translations would be properly used by the installer.
 
-## Linux
+### Linux
 
-Similarly to the Windows installer nightlies, GIMP now gets a **nightly
+Similarly to the Windows installer nightlies, GIMP now gets a **weekly
 flatpak**, i.e. a flatpak built out of development code, entirely
-automated and running on a weekly schedule.
+automated.
 
-Install the nightly repository to get our weekly updates with this
+Install the "nightly" repository to get our weekly updates with this
 command:
 
> flatpak install --user https://nightly.gnome.org/repo/appstream/org.gimp.GIMP.flatpakref
 
-ℹ If you installed both the `stable`, `beta` (development releases) and
-`master` (nightlies) repositories, your desktop will only see one at once.
-You may select exactly which version it sees and start with the following
-command (e.g. selecting `stable` as default):
+If you installed both the `stable`, `beta` (development releases) and
+`master` (weeklies) repositories, your desktop will only see one of them
+at any given time. You can select exactly which version it sees and start
+with the following command (e.g. selecting `stable` as default):
 
> flatpak make-current --user org.gimp.GIMP stable
 
-Then if `stable` was made to be your default GUI-run GIMP, you may run
-the other versions with the following command line (e.g. the nightlies):
+Then if `stable` was made to be your default flavor of GIMP, you can run
+the other versions with the following command (e.g. the weeklies):
 
> flatpak run org.gimp.GIMP//master
 
-*These information are also available in the the [download page](https://www.gimp.org/downloads/devel/).*
+*This information is also available on the [downloads page](https://www.gimp.org/downloads/devel/).*
 
-⚠️ Be warned that a nightly being purely automated builds, without any
-human verification and happening at a semi-random time during the
-development process, you may end up with very broken software at times
-(even though we try to never leave the repository in a dire state).
+⚠️ Please keep in mind that a weekly build is purely automated, there is
+no human verification, is happens at semi-random time during the
+development process. Hence you may end up with very broken software
+at times even though we try to never leave the repository in a dire state.
 It is even less safe than development releases. People are welcome to
-test our nightlies to help us with feedbacks and bug reports, but you
-should not expect these builds to be considered as anything finale or
-even usable. ☢️
-
-## macOS
+test our weekly builds to help us with feedback and bug reports, but you
+should not expect these builds to be any close to stable software or even
+usable. ☢️
 
-Finally an exciting news for macOS users: we recently got a new active
-contributor, Lukas Oberhuber, who started to work on the development
-package. They already have a working local build and are still in the
-process of tweaking the remote automated build. It means we might have
-finally our first macOS development release (hopefully for GIMP 2.99.8)
-soon.
+### macOS
 
-Additionally they already contributed code fixes in GIMP source as well,
-not only package scripts, which was direly needed for macOS.
+Finally, there's some exciting news for macOS users: we were recently
+joined by a new contributor, Lukas Oberhuber, who started working on the
+development package. Lukas already has a working local build, he is
+currently tweaking the remote automated build. So we might finally have
+our first macOS development release (hopefully for GIMP 2.99.8) soon.
+Lukas also contributed fixes to GIMP source code to better support macOS.
 
-This excellent news does not invalidate the call for more macOS
-contributors we have made many times lately. A single contributor
+While this is excellent news, it does not invalidate the call for more
+macOS contributors we have made many times before. A single contributor
 (furthermore for both packaging and development!) is a very low [bus
 factor](https://en.wikipedia.org/wiki/Bus_factor). The more
-contributors, the better, so if you want to help in order to ensure
-sustainability of the macOS package, you are still very welcome.
+contributors, the better, so if you want to help to ensure
+sustainability of macOS packaging, you are still very much welcome to join!
 
-## Label usage in merge requests
+### Automatic builds for merge requests
 
-Additionally to being able to test validated code, it can be useful at
-times to facilitate in-review code testing.
+To facilitate in-review code testing, we now provide automatic builds
+for merge requests. If you are planning to contribute a patch using
+this Gitlab feature, please add the `5. Windows Installer` and/or
+`5. Flatpak package` label to a newly created merge request. This will
+trigger building a Windows installer and/or a standalone flatpak.
+We expect this to be helpful for testing new features and bug fixes.
 
-This is why the Continuous Integration scripts were also modified to
-build automatically a test Windows installer and/or flatpak (as
-standalone package, no flatpak repository) for any contributed *Merge
-Request* if we add the `5. Windows Installer` and/or `5. Flatpak
-package` respectively.
-
-This can be a powerful tool for having faster feedbacks with new
-contributors and non-developers willing to test new features or complex
-bug fixes.
-
-## Contribution process
+## Updated coding style guide
 
 GIMP source repository now provides a very nice first draft of [Coding
-style guide](https://gitlab.gnome.org/GNOME/gimp/-/blob/master/CODING_STYLE.md),
-written by Stanislav Grinkov, based on the main current guidelines (some
-of them used to be written in the `HACKING` file, with few details, many
-more were either passed down through discussion channels and patch
-reviews or by looking at existing code).
+style guide](https://gitlab.gnome.org/GNOME/gimp/-/blob/master/CODING_STYLE.md) written by Stanislav 
Grinkov. The new guide combines guidelines
+available in the `HACKING` file and information passed down through
+discussion channels like IRC, patch reviews etc.
 
-There is no doubt that this guide can still be improved as we do love
-very neat and organized code. In any case, this is a very nice first
-version.
+We expect this draft to receive further improvements as we do love
+very neat and organized code. In any case, this is a great start!
 
-# GEGL and babl
+## GEGL and babl
 
-TODO
+We did not request a new set of babl and GEGL releases for 2.99.8.
+All the changes we [announced in v2.10.28](https://www.gimp.org/news/2021/09/18/gimp-2-10-28-released/) 
still apply here.
 
-# Downloading GIMP 2.99.8
+## Downloading GIMP 2.99.8
 
-As usual GIMP 2.99.8 is available on [GIMP official website
+As usual, GIMP 2.99.8 is available on [GIMP official website
 (gimp.org)](https://www.gimp.org/downloads/devel/):
 
 * The Linux development flatpak has already been published so that
@@ -330,11 +305,11 @@ As usual GIMP 2.99.8 is available on [GIMP official website
 
 * The macOS DMG package will hopefully be published [*soonish*](#macos).
 
-# Team news
-## Developers
+## Team news
+### Developers
 
 Daniel Novomeskỳ is now a core developer with git access, for their
-continuous follow-up contributions to the HEIF/HEIC/AVIF plug-in as well
+continuous contributions to the HEIF/HEIC/AVIF plug-in as well
 as the brand new JPEG XL plug-in.
 
 *Code contributors on GIMP 2.99.8*: TODO