[gimp-web] content: update GIMP 2.99.10 news.

[Jehan <jehanp src gnome org>]

commit 02c781c04f5a9e712d103d79430e10aadce00744
Author: Jehan <jehan girinstud io>
Date:   Thu Feb 24 23:48:12 2022 +0100

    content: update GIMP 2.99.10 news.

 .../2022/2022-02_GIMP-2.99.10_Released/index.md    | 173 +++++++++++----------
 1 file changed, 88 insertions(+), 85 deletions(-)
---
diff --git a/content/news/2022/2022-02_GIMP-2.99.10_Released/index.md 
b/content/news/2022/2022-02_GIMP-2.99.10_Released/index.md
index 6e1f8fe2..e7eb07ec 100644
--- a/content/news/2022/2022-02_GIMP-2.99.10_Released/index.md
+++ b/content/news/2022/2022-02_GIMP-2.99.10_Released/index.md
@@ -76,7 +76,7 @@ I could just search said keyword.
 
 For the geekiest of us: by default, this uses simple text search, but in
 Preferences, tab "Interface", you can also set the search entry
-to use the Glob or Regular Expression syntax!
+to use the Glob or Regular Expression syntaxes!
 
 <figure>
 <img src="{attach}gimp-2-99-10-layer-set-preferences.png" alt="Layer sets settings"/>
@@ -174,12 +174,12 @@ the visibility and especially the lock buttons:
 ### Enabling/Disabling dynamics simplified
 
 It is now possible to enable and disable dynamics in a single checkbox,
-instead of tediously having to select the "Dynamics Off" neutral
+instead of tediously having to select the "*Dynamics Off*" neutral
 dynamics. Obviously this neutral dynamics has been removed from the list
 of installed data.
 
 It allows to switch dynamics painting in a single click, and without
-having to remember which dynamics you were using for switching back.
+having to remember which dynamics you were using when switching back.
 
 <figure>
 <img src="{attach}gimp-2-99-10-dynamics-enabling.webp" alt="Enabling/disabling dynamics in a click"/>
@@ -189,9 +189,9 @@ having to remember which dynamics you were using for switching back.
 </figure>
 
 For advanced user, we also set up the new action
-"context-dynamics-toggle". It means you can create a shortcut
-(`Edit > Keyboard Shortcuts` menu) to switch the dynamics painting
-for even faster work.
+"context-dynamics-toggle". Thus you can create a shortcut (`Edit >
+Keyboard Shortcuts` menu) to switch the dynamics painting for even
+faster work.
 
 <figure>
 <img src="{attach}gimp-2-99-10-dynamics-shortcut.png" alt="Shortcut settings for enabling/disabling 
dynamics"/>
@@ -202,7 +202,7 @@ Shortcuts dialog</em>
 </figure>
 
 ## New Core Features
-### New feature for Line Art mode of bucket fill tool
+### New option in "Line Art" mode of bucket fill tool
 
 We added a new option "*Allow closing lines in selected layer*" in the
 "Fill by line art detection" mode of the bucket fill tool. The name is
@@ -216,15 +216,15 @@ as closure data.
 
 Once again, it is **not** a source for line art detection, which means
 it doesn't trigger any recomputing. It is additional data for manual
-line closure only after line art and closure computation.
+line closure only *after* line art and closure computation.
 
 One of the main usage could be to set the "*Maximum gap length*" to 0,
-which totally disable the line art closure computation, hence having
-much faster computing on big line art images. Then you'd rely solely on
-manually closed line arts. Unfortunately sometimes you don't want to
-close a line art with your **line** color/brush/style, you want to close
-it with your **fill** color/brush/style. This is when this option comes
-into play.
+which totally disables line art closure computation, hence having much
+less computing (i.e. faster on big line art images). Then you'd rely
+solely on manually closed line arts. Unfortunately sometimes you don't
+want to close a line art with your **line** color/brush/style, you want
+to close it with your **fill** color/brush/style. This is when this
+option comes into play.
 
 For instance, here is how you could fill the line art with the smart
 closing which could oversegment if you don't tweak properly the
@@ -301,12 +301,12 @@ Portuguese-localized GIMP:
 </figure>
 
 Some more work might happen on this Welcome Dialog. For instance,
-proposing a "Customization" tab for some of the more controversial
-settings (such as themes and icons) will likely be added.
+a "Customization" tab for some of the more controversial settings (such
+as themes and icons) will likely be added.
 
 There is also the question about adding more "everyday use" features,
-such as a list of some of the lastly opened images, or a "New Image"
-option, avoiding going in menus (or using shortcuts).
+such as a list of the last opened images, or a "New Image" option,
+avoiding going in menus (or using shortcuts).
 Of course it means giving the ability to open the dialog at every start
 as an option (unlike now where it will only open once after a new
 update).
@@ -320,7 +320,7 @@ of this slider.
 So the widget has now been moved to the `libgimpui` library, making it
 usable by any plug-in which wants a nice looking and efficent slider
 with slow relative moves, fast drag moves and direct keyboard edits (see
-some of the [usability work on an older
+some of the [usability work in an older
 news](https://www.gimp.org/news/2020/12/25/gimp-2-99-4-released/#slider-widget)),
 all the while maximizing the space.
 
@@ -349,7 +349,7 @@ abilities:
 * new support for loading 32-bit per channel images (some code
   existed yet may have never really worked).
 * Add extra layer groups when loading PSD images with clipping
-  layers: PhotoShop handles clipping layers in a different way than
+  layers: Photoshop handles clipping layers in a different way than
   GIMP. The only way to have it look the same is by adding extra
   layer groups. PSD layers that have clipping set, combined with the
   first non clipping layer below it are grouped together in a new
@@ -357,11 +357,11 @@ abilities:
   merged image unless there are other PSD elements in play that we
   don't handle yet.
 * PSD layers with clipping set need clip to backdrop as composite
-  mode: Certain PSD layers have a flag called clipping set to 1. We
+  mode: certain PSD layers have a flag called clipping set to 1. We
   were not handling this flag and had some reports about colors
-  bleeding where they were not supposed to. We are going to set
-  GIMP's layer composite mode to "Clip to backdrop" which is the closest
-  we can get to PhotoShop's clipping. With this, the colors won't bleed
+  bleeding where there were not supposed to. We are going to set
+  GIMP's layer composite mode to "Clip to Backdrop" which is the closest
+  we can get to Photoshop's clipping. With this, the colors won't bleed
   anymore.
 
 ### JPEG-XL
@@ -370,7 +370,7 @@ Our recent JPEG-XL support also continues to improve:
 
 * Bit depth now selectable in JXL export.
 * Import in 8-bit and 16-bit integer precision now possible for
-  lossless images. (GIMP used to import all JXL images as 32-bit float
+  lossless images (GIMP used to import all JXL images as 32-bit float
   precision images).
 * New very fast export settings: thunder and lightning (fastest).
 * Compression slider is disabled for lossless.
@@ -385,20 +385,20 @@ location for each cursor in the file.
 
 We definitely removed support for the **KDE** and **GNOME** portals for
 screenshots. On recent versions of these portals, new security
-restrictions was making them unusable for GIMP which didn't have the
+restrictions were making them unusable for GIMP which didn't have the
 permissions.
 
-We now use the Freedesktop portal only on **Linux** (when the direct X11
-codepath is not available, i.e. when we are on Wayland) which is the new
-recommended logic by both the GNOME and KDE teams.
+We now use only the Freedesktop portal on **Linux** (unless the direct X11
+codepath is available, i.e. on Wayland) which is the new recommended
+logic by both the GNOME and KDE teams.
 
-On **Windows**, the Screenshot plug-in finally get a "cursor capture"
-option.
+On **Windows**, the Screenshot plug-in finally gets an "Include mouse
+pointer" option.
 
 ### HEIF
 
 The HEIF plug-in used to have some heuristic for the choice of the
-bit-depth defaults when exporting, depending the image's encoding
+bit-depth defaults when exporting, depending on the image's encoding
 settings. This heuristic didn't agree with everyone's logic.
 
 Also it was going against the settings storage which are now a basic
@@ -415,24 +415,24 @@ We have 2 plug-ins depending on the WebkitGTK library:
    machine has a browser, so it feels redundant. Its main advantage
    though was its very nice "topic tree", which is basically a side menu
    to navigate the documentation quite efficiently.
-2. web-page: a webpage screenshot plug-in allowing to shot the whole
+2. `web-page`: a webpage screenshot plug-in allowing to shot the whole
    page, not just what is visible. This is a very neat feature, yet it
-   also appeared on most web browser by default these days. For instance
-   on Mozilla Firefox, you can *right-click* then select "Take
+   also appeared on most web browsers by default these days. For
+   instance on Mozilla Firefox, you can *right-click* then select "Take
    Screenshot" in the contextual menu of a page.
 
 On the other hand:
 
 1. WebkitGTK is very hard and long to build. More than once we
    encountered issues and are dreading them. Actually our macOS package
-   don't build it right now because of such issues.
+   don't build it right now because of such difficulties.
 2. From what we gather, recent versions are officially unsupported on
    Windows right now and we don't know when or if it will change soon.
 
 So we have 2 of our main platforms not using it, it makes a lot of
 packaging problems, all this for features which are a bit redundant with
 browser nowadays anyway. This is why we decided to drop the ball, at
-least for now, by deprecating these 2 plug-ins. Unless situation change
+least for now, by deprecating these 2 plug-ins. Unless situation changes
 in any positive way, we are not recommending packagers to build these
 anymore.
 
@@ -450,12 +450,12 @@ build cases, so we refactored it:
 * Our Continuous Integration now has a new weekly job to verify that the
   meson and autotools build rules are perfectly synced regarding icons.
 * We started to group icons in semantic lists when possible to help with
-  knowing the right sizes to generate in the PNG case.
+  deciding the right sizes to generate in the PNG case.
 
 By the way, why we keep the PNG variant option needs to be explained. We
 were originally planning to drop it, but it turns out that the `librsvg`
-dependency used as GdkPixbuf loader, ported to Rust in its later
-versions, doesn't build on each platform and architecture (as Rust is
+dependency used as `GdkPixbuf` loader, ported to Rust in its later
+versions, doesn't build on all platforms and architectures (as Rust is
 not fully portable yet).
 It means that some platforms may need to either use very old versions of
 librsvg or may even prefer to use PNG-only icons. This is why we keep
@@ -494,9 +494,9 @@ them is the ability to install older versions of the package easily. It
 can be a pretty neat developer tool when we want to test something on an
 older version of GIMP, a kind of `git bisect` but with flatpak packages.
 Nevertheless listing the old versions, uninstalling your current
-version, installing the relevant older, and remember the command lines
-for all this (since we don't do this daily either) was making it hardly
-usable in real life.
+version, installing the relevant older version, and remembering the
+command lines for all this (since we don't do this daily either) was
+making it hardly usable in real life.
 
 This is where this tool comes in:
 
@@ -583,55 +583,59 @@ start](https://gitlab.gnome.org/GNOME/gimp/-/blob/master/devel-docs/README.md).
 ## Improved API for plug-ins
 
 The work on the API is still going full on. Here are the most noteworthy
-changes which happened during GIMP 2.99.10 time frame:
+changes which happened during GIMP 2.99.10 time frame.
+
+Changes in `libgimp`:
 
 * `GimpStringArray` type was removed in favor of `GStrv`. Various
   libgimp API were updated to use `GStrv`, and relevant plug-in procedures
   with
   `GStrv` arguments or return values were updated as well.
 * New functions:
-  + `gimp_context_are_dynamics_enabled()`
-  + `gimp_context_enable_dynamics()`
-  + `gimp_item_get_lock_visibility()`
-  + `gimp_item_set_lock_visibility()`
-  + `gimp_pdb_run_procedure_config()`
+    + `gimp_context_are_dynamics_enabled()`
+    + `gimp_context_enable_dynamics()`
+    + `gimp_item_get_lock_visibility()`
+    + `gimp_item_set_lock_visibility()`
+    + `gimp_pdb_run_procedure_config()`
 * Removed functions:
-  + `gimp_item_get_linked()`
-  + `gimp_item_set_linked()`
-Changes in libgimpui:
+    + `gimp_item_get_linked()`
+    + `gimp_item_set_linked()`
+
+Changes in `libgimpui`:
+
 * New widgets:
-  + `GimpLabelColor` (now used by default for GimpRGB properties in
-    `GimpProcedureDialog)
-  + `GimpLabelEntry` (now used by default for string properties in
-    `GimpProcedureDialog)
-  + `GimpSpinScale` (see [above](#going-further-with-our-compact-slider-widget))
+    + `GimpLabelColor` (now used by default for `GimpRGB` properties in
+      `GimpProcedureDialog)
+    + `GimpLabelEntry` (now used by default for string properties in
+      `GimpProcedureDialog)
+    + `GimpSpinScale` (see [above](#going-further-with-our-compact-slider-widget))
 * New functions:
-  + `gimp_color_area_enable_drag()`
-  + `gimp_event_triggers_context_menu()`: alternative to
-    `gdk_event_triggers_context_menu()` with the additional ability of
-    using button release events as contextual menu triggering
-    (instead of press events), which might be prefered in some
-    cases. Other than this, it uses exactly the same conditions as
-    its GDK counterpart.
-  + `gimp_procedure_dialog_get_spin_scale()`
-  + `gimp_prop_label_color_new()`
-  + `gimp_prop_label_entry_new()`
-  + `gimp_prop_spin_scale_new()`
-  + `gimp_prop_widget_set_factor()`
+    + `gimp_color_area_enable_drag()`
+    + `gimp_event_triggers_context_menu()`: alternative to
+      `gdk_event_triggers_context_menu()` with the additional ability of
+      using button release events as contextual menu triggering
+      (instead of press events), which might be prefered in some
+      cases. Other than this, it uses exactly the same conditions as
+      its GDK counterpart.
+    + `gimp_procedure_dialog_get_spin_scale()`
+    + `gimp_prop_label_color_new()`
+    + `gimp_prop_label_entry_new()`
+    + `gimp_prop_spin_scale_new()`
+    + `gimp_prop_widget_set_factor()`
 * Improved functions:
-  + `gimp_procedure_dialog_get_widget()` can now generate widgets of
-    type `GimpSpinScale` (for int/double properties) and GimpLabelColor
-    or `GimpColorButton` (for GimpRGB properties).
-  + `gimp_procedure_dialog_get_color_widget()` now only return
-    `GimpLabelColor` widgets (editable or not).
+    + `gimp_procedure_dialog_get_widget()` can now generate widgets of
+      type `GimpSpinScale` (for int/double properties) and GimpLabelColor
+      or `GimpColorButton` (for `GimpRGB` properties).
+    + `gimp_procedure_dialog_get_color_widget()` now only return
+      `GimpLabelColor` widgets (editable or not).
 
 Also the Vala bindings `gimp-3.vapi` and `gimp-ui-3.vapi` were renamed
 to `gimp-3.0.vapi` and `gimp-ui-3.0.vapi` respectively in the autotools
 build (now consistent with meson).
 
-By the way, note that it seems we have issues with the Vala and Lua
-plug-ins on Windows in the installer we are providing here. We don't
-know why yet and still need to investigate.
+By the way, it seems we have issues with the Vala and Lua plug-ins on
+Windows in the installer we are providing. We don't know why yet and
+still need to investigate.
 
 ## Wayland and macOS support
 
@@ -676,7 +680,7 @@ Yet in some situations, a [LUT (Look-Up
 Table)](https://en.wikipedia.org/wiki/Lookup_table#Lookup_tables_in_image_processing)
 could perform better.
 This is why a new automatic step of LUT creation will be triggered in
-some case, and its conversion speed compared with the usual universal
+some cases, and its conversion speed compared with the usual universal
 conversion paths.
 
 Right now one drawback is that it might actually slow down slightly the
@@ -747,7 +751,7 @@ tool.
 
 42 people contributed to GIMP 2.99.10:
 
-* 17 developers contributed to `GIMP` code base:
+* 17 developers contributed to `GIMP` code base for this micro version:
     - 1 developer with more than 300 commits (Jehan)
     - 4 developers with 10 to 30 commits (Jacob Boerema, Niels De Graef,
       Lukas Oberhuber and Daniel Novomeský)
@@ -806,8 +810,7 @@ to our new packager, Lukas:
 ## Downloading GIMP 2.99.10
 
 As usual, GIMP 2.99.10 is available on [GIMP official website
-(gimp.org)](https://www.gimp.org/downloads/devel/) in 3 types of
-packages:
+(gimp.org)](https://www.gimp.org/downloads/devel/) in 3 package formats:
 
 * Linux development flatpak
 * Windows installer
@@ -821,7 +824,7 @@ OS](https://twitter.com/haikunauts/status/1489019411637972997) (yet
 another operating system, not a mainstream one) and is now provided
 through their packaging system. Even though we know it well, it always
 amazes us how cross-platform GIMP is as it can be found on nearly every
-operating system (yes GIMP is on GNU/Hurd too from what we were told!)
+operating system (yes GIMP is on GNU/Hurd too from what we are told!)
 and micro-architecture there is. 😊
 
 ## What's next
@@ -835,9 +838,9 @@ finished.
 The GTK port is another big blocker; important work in this direction
 has been started by some contributors regarding a move to the
 `GApplication` and `GtkApplication` frameworks and the `GAction` port.
-These patches are still heavily under work and review and have not been
-merged in any form in GIMP 2.99.10, so we will have the opportunity to
-talk more about it on the next release most likely.
+These patches are still heavily under work and need review thus it has
+not been merged in any form in GIMP 2.99.10. We will most likely have
+the opportunity to talk more about it on the next release.
 
 Meanwhile work related to Wayland and macOS support are still taking
 quite a bit of developer time as you can see.