[gimp-web] Some more fixup pass on GIMP 2.99.2 news.

[Jehan <jehanp src gnome org>]

commit 745a75a1466fa0c3c820957eec84e97033f7b222
Author: Jehan <jehan girinstud io>
Date:   Fri Nov 6 18:36:54 2020 +0100

    Some more fixup pass on GIMP 2.99.2 news.

 .../2020/2020-11_GIMP-2.99.2_Released/index.md     | 213 +++++++++++----------
 1 file changed, 108 insertions(+), 105 deletions(-)
---
diff --git a/content/news/2020/2020-11_GIMP-2.99.2_Released/index.md 
b/content/news/2020/2020-11_GIMP-2.99.2_Released/index.md
index 50022732..a76bf45a 100644
--- a/content/news/2020/2020-11_GIMP-2.99.2_Released/index.md
+++ b/content/news/2020/2020-11_GIMP-2.99.2_Released/index.md
@@ -1,5 +1,5 @@
 Title: GIMP 2.99.2 Released
-Date: 2020-11-05
+Date: 2020-11-06
 Category: News
 Authors: Wilber
 Slug: gimp-2-99-2-released
@@ -31,8 +31,8 @@ Release highlights:
 
 The first difference will be visual as you will notice that GIMP got a
 bit more of a modern look and it can also use some new widgets (instead
-of redeveloping them on GTK2) or some client-side window decorations on
-various dialogs. But the aesthetic differences are far from being the
+of redeveloping them on GTK2) as well as client-side window decorations
+on various dialogs. But the aesthetic differences are far from being the
 main appeal of GTK3.
 
 <figure>
@@ -47,14 +47,14 @@ main appeal of GTK3.
 One of the main issues of GTK2 was the absent support for high pixel
 density displays (e.g. small screens with high resolution or big screens
 with extremely high resolution) which has become more widespread,
-especially among graphics professionals. GIMP 2.10 came with some
-partial workaround which was acceptable only in some limited cases but
-was not really appropriate for intense use of the software.
+especially among graphics professionals. GIMP 2.10 came with partial
+workaround which was acceptable only in some limited cases but was not
+really appropriate for intense use of the software.
 
 GTK3 brings proper support to GIMP so it will follow your system-set scale
 settings.
 
-*Status*: basically done, some custom widgets could still need an update.
+*Status*: done, some custom widgets might still need an update.
 
 ### Improved input devices support
 
@@ -66,10 +66,11 @@ instability of the software (though this issue got mostly worked around
 on GTK2 by GIMP developers in the v2.8 release series).
 
 GIMP 3 (hence this first development release) is bringing hotplug support,
-which basically means: start GIMP, plug your tablet, done. You are ready
-to draw, with pressure, tilt, and everything.
+which means: start GIMP, plug your tablet, done. You are ready to draw,
+with pressure, tilt, and everything.
 
-We are also trying to improve general support by making the advanced configuration of input devices easier 
to do.
+We are also trying to improve general support by making the advanced
+configuration of input devices easier to set.
 
 A while ago, we also experimented with support for touch gestures like
 zooming, panning, rotating etc. We did not finish this work because we
@@ -81,12 +82,12 @@ prevent unwanted input while working with a stylus (high-end tablets often
 come with a physical switch for this nowadays, and this can also be disabled
 in tablet settings). With this in mind, we have decided to not make it
 a priority compared to some other work-in-progress. So we are not sure
-whether  specific gesture support will make it to GIMP v3.0. We do
+whether specific gesture support will make it to GIMP v3.0. We do
 welcome patches from anyone willing to make it one's priority though.
 
 *Status*: some work needs to be done to simplify configuration dialog as
-the support for legacy features is either not needed anymore nowadays or
-can be done better. We might also need to add support for Wayland-specific
+the support for legacy features is either not needed anymore or can be
+done better. We might also want to add support for Wayland-specific
 features related to input devices.
 
 ### Theming
@@ -106,13 +107,15 @@ won't be necessary anymore as symbolic icons will be recolored according
 to your theme.
 
 Finally, the "dark theme" is a core concept of GTK3, which means,
-for instance, that even window decorations get recolored as you can see
-in the screenshot above.
+for instance, that even window decorations get recolored as you could
+see in the screenshot above.
 
-Also, the same theme could propose both a dark and a light variant, so
-the *Theme* preferences shows the *"Use dark theme variant if available"*
-checkbox. Similarly, icon themes may propose both symbolic and color icons. Which is why the *"Icon Theme"* 
preferences page has a *"Use symbolic icons if
-available"* switch so that you could choose your preferred style.
+Also a same theme could propose both a dark and a light variant, so the
+*Theme* preferences page shows a *"Use dark theme variant if available"*
+checkbox. Similarly, icon themes may propose both symbolic and color
+icons. Which is why the *"Icon Theme"* preferences page has a *"Use
+symbolic icons if available"* switch so that you could choose your
+preferred style.
 
 <figure>
 <img src="{attach}gimp-2.99.2-themes.jpg" alt="Theme switching"/>
@@ -123,21 +126,23 @@ available"* switch so that you could choose your preferred style.
 
 *Status*: waiting for theme contributors.
 
-We've already done most if not all changes in source code related to
-theming. For now, GIMP 2.99.2 only lists the "System" theme, which
-basically GIMP will follow your system-wide GTK theme. This is a regression
-from 2.10 that we intend to fix in time for GIMP 3.0 by reintroducing
-a default custom theme with a neutral dark/light variant as well as
-a neutral middle-gray custom theme.
+Code-side, changes related to theming are basically done. Now we need a
+new default theme.
+For now, GIMP 2.99.2 only lists the "System" theme, which lets GIMP
+follow your system-wide GTK theme. This is a regression from 2.10 that
+we intend to fix in time for GIMP 3.0 by reintroducing a default theme
+with a neutral dark/light variant as well as a neutral middle-gray
+custom theme.
 
 The main issue with system themes is that they cover very basic desktop
 use cases. Meanwhile, advanced graphics work requires a neutral gray theme
 to avoid polluting your color perception. This is the main reason why
 GIMP needs to default to a neutral color theme with symbolic icons.
 
-Colored icon themes can still be an option, and, in fact, we are pretty
-sure that the community will soon come up with good-looking custom themes.
-This is a great way to contribute to GIMP as a non-developer!
+Colored themes and icons are still an option, and, in fact, we are
+pretty sure that the community will soon come up with good-looking
+custom themes. This is a great way to contribute to GIMP as a
+non-developer!
 
 ### Wayland support
 
@@ -154,7 +159,7 @@ address that, whether they arrive to GIMP, GTK, or another relevant part
 of the technology stack. If you are interesting in helping out, here is the
 [list of Wayland-related 
bugs](https://gitlab.gnome.org/GNOME/gimp/-/issues?scope=all&utf8=%E2%9C%93&state=opened&label_name[]=Environment%3AWayland).
 
-Appropriate Wayland support also means we need need to reimplement a few
+Appropriate Wayland support also means we need to reimplement a few
 features through so called portals. We have already done this for the
 screenshot plug-in (using Freedesktop, GNOME, and KDE portals), and there
 is some ongoing work to fix on-display color picking (already works in KDE,
@@ -180,7 +185,7 @@ was carefully designed following discussions and was tested in production.
 <figure>
 <img src="{attach}gimp-2.99.2-multi-layer-selection.png" alt="Selecting multiple layers in Layers dockable"/>
 <figcaption>
-<em>Selecting 4 layers at once to organize them or transform them at once</em>
+<em>Selecting 4 layers to organize them or transform them at once</em>
 </figcaption>
 </figure>
 
@@ -214,14 +219,14 @@ selection to paths and channels soon.
 
 Finally, painting and GEGL operations (filters) are still limited to
 single layers. Adding ability to paint or run pixel operations on
-several pixels at once will probably require some additional interface
+several layers at once will probably require some additional interface
 specification and designing to prevent undesired consequences like
 extremely slow operation or the ability to cancel a long-running process.
 
 ## Plug-in API
 
 We had to break the plug-in APi to introduce many improvements, although we
-took a special care not to break things where it wasn't necessary to do so. 
+took a special care not to break things where it wasn't necessary to do so.
 
 Porting a single-file plug-in from GIMP 2.10 to GIMP 3 usually takes between
 5 and 30 minutes. We are working on a porting documentation to be released
@@ -263,14 +268,14 @@ regular polling).
 ### GIO usage for file handling
 
 Another change in our API is that paths are now handled as `GFile`,
-which means using the GLib/GIO API.
+which implies using the GLib/GIO API.
 
 While it may seem a bit cumbersome (as it adds the additional step of
 creating and managing a GFile), this allows much more robust file
-handling. In particular, GIMP doesn't have to take care about path
-character encoding (a real issue when many developers just assume
-everyone uses the same encoding as you) hence broken paths and
-non-portable code.  Also we don't have to deal with difference of
+handling. In particular, you won't have to take care about path
+character encoding (a real issue when developers just assume everyone
+uses the same encoding as themselves) hence broken paths and
+non-portable code. Also we don't have to deal with difference of
 operating systems regarding folder separation or file system notations.
 Working with a `GFile` makes internal representation transparent and
 file handling robust.
@@ -280,17 +285,18 @@ of installed GIO modules, in particular loading or saving from/to remote
 locations (even possibly through secure channels like HTTPS).
 This opens a wide range of possibilities.
 
-GIO port of file handling had also be done in the core code of GIMP,
-back in GIMP 2.10 initial release. We are now bringing the advantages to
+GIO port of file handling had been done in the core code of GIMP, back
+for GIMP 2.10 initial release. We are now bringing the advantages to
 plug-in developers as well in GIMP 3.0.
 
-*Status*: This is basically done.
-For binding languages through GObject Introspection, it is to be noted
-that they also have full access to GLib/GIO API so they are already able
-to create GFile from paths or URI without any problem.
-Yet for legacy manual bindings, such as the `script-fu` (Scheme), we
-are working on it (a patch even already exists, but needs to be
-reviewed) as they currently don't have GFile access.
+*Status*: done, except with legacy bindings.
+
+Language bindings through GObject Introspection also have full access to
+GLib/GIO API so they are already able to create GFile from paths or URI
+without any problem.
+Yet legacy manual bindings, such as `script-fu` (Scheme), don't have
+GFile access. We are working on it (a patch even already exists, but
+needs to be reviewed).
 
 ### Plug-in declaration
 
@@ -302,30 +308,28 @@ help plug-in developers.
 
 The way your plug-in procedure's arguments are now handled has also been
 standardized, in particular using config `GObject` properties. This is
-easier to deal with as a generic logics. Especially it allows to
-generate many features. For instance, it will help us generate dialogs
-on demand for plug-ins who do not want to tinker with `GTK` or other
-toolkit themselves. It also simplify and standardize argument saving for
-subsequent calls or a same procedure.
+easier to deal with as a generic logics. Especially the same config
+object allows us to generate many features. For instance, it will help
+generate dialogs on demand for plug-ins who do not want to tinker with
+`GTK` or other toolkit themselves. It also simplify and standardize
+argument saving for subsequent calls or a same procedure.
 
 Eventually this is also part of the base work for a future
 recording/macro feature (very unlikely to be in GIMP 3.0, but this is
 part of a ground work towards such feature) since we will be able to
-reliably save the arguments used when running plug-ins (even when
-calling them through a GUI which can be bypassed when running the
-macro).
+reliably save the arguments used when running plug-ins.
 
 *Status*: though the main part of this API is done, more needs to happen
-before the release, and in particular we are still tinkering
-with the argument representation.
+before the release, and in particular we are still tinkering with the
+argument representation.
 
 ### Bindings
 
-We have made the full API introspected through [GObject
-Introspection](https://gi.readthedocs.io/en/latest/). In particular, it
-means that the API should be fully usable in a wide range of language
-bindings. We have only tested a few so far, so we can confirm that GIMP
-can now be scripted (additionally to C and C++ of course) with:
+We have introspected the full API through [GObject
+Introspection](https://gi.readthedocs.io/en/latest/). It means that GIMP
+API should be fully usable in a wide range of language bindings. We have
+only tested a few so far, so we can confirm that GIMP can now be
+scripted (additionally to C and C++ of course) with:
 
 * Python 3
 * JavaScript
@@ -337,15 +341,15 @@ Python 2 notably, is that a custom layer API is not needed anymore.
 
 Also GIMP 2 bindings used to be made around the PDB protocol which is
 only a subset of the full C `libgimp` API. The new bindings are built
-around `libgimp` itself. This basically means that plug-ins in Python 3,
-Javascript, Lua or Vala (or any future introspected binding) will have
-the same possibilities as C plug-ins. This is a bright new world for
-GIMP plug-in developers!
+around `libgimp` itself. Therefore plug-ins in Python 3, Javascript, Lua
+or Vala (or any future introspected binding) will have the same
+possibilities as C plug-ins. This is a bright new world for GIMP plug-in
+developers!
 
 Another consequence is that the API is basically the same for all these
 languages, apart for language idiosyncracies.
-Therefore if finding an intersection of a drawable with a selection in C
-is:
+For instance if finding an intersection of a drawable with a selection
+in C is:
 
 ```C
 success = gimp_drawable_mask_intersect (drawable, &x, &y, &width, &height);
@@ -384,46 +388,46 @@ Gimp.edit_copy([drawable1, drawable2, drawable3])
 ```
 
 Not only do these binding now have access to the full GIMP API, but they
-also have access to many more introspected API used as dependencies to
+also have access to many more introspected APIs used as dependencies to
 GIMP. For instance a plug-in can have access to the full GLib/GIO, GTK,
 Pango, Cairo APIs as well as the babl and GEGL API (for easier pixel
 manipulation and access to a massive range of existing operations). This
 was one of the main limitation of the former Python 2 binding, which
 could not manipulate pixels with GEGL.
 
-*Status*: of course some people are regretting the facilities provided
-by the specific Python binding, such as automatic dialog creation. This
+*Status*: some people are regretting the facilities provided by the
+former Python 2 binding, such as automatic dialog creation. This
 is worked on right now (some embryo of dialog generation has even
 already landed in the development branch after 2.99.2 release) hence
 should be available for the next development release. The best part is
 that such API will be done on the main API, thus available to all
 bindings, not just Python or Scheme.
 This is one of the biggest advantages of introspected API compared to
-manually maintained bindings. Rather than reimplementing nice features
+manually maintained bindings: rather than reimplementing nice features
 in every available binding, we will provide them in the main API so that
 every developer can enjoy them, whatever your prefered language.
 
 Finally Script-fu is not one of the introspected bindings (though there
 is supposedly GObject Introspecting scheme bindings, but we haven't
-tested any yet) and still mostly works as its own extension. Yet some
-issues regarding some of the API changes have been raised (for instance
-the inability to create `GFile` as discussed earlier) and will have to
-be fixed before finale stable release.
+tested any yet) and still mostly works as its own extension. Yet issues
+regarding some of the API changes have been raised (for instance the
+inability to create `GFile` as discussed earlier) and will have to be
+fixed before finale stable release.
 
 ### Goat exercises
 
 For each of the tested binding languages, we created a plug-in called
-"Goat exercise", which is basically a demo for creating plug-ins. You
-can call it a "*GIMP Hello World!*".
-
-Each Goat Exercise does exactly the same thing (but in its own
-language): it creates a dialog with a label, buttons and a text view
-(GTK+ and GLib/GIO demo); one of the buttons triggers a processing to
-modify the active layer (GEGL demo and GIMP API demo); all this while
-showing its own source code inside the text view (making it easy to
-inspect the code from within GIMP with a button sending you to the
-repository file if you want to check out the last version, comfortably
-in your code editor).
+"Goat exercise", which is a demo for creating plug-ins. You can call it
+a "*GIMP Hello World!*".
+
+Each Goat Exercise does exactly the same thing in its own language: it
+creates a dialog with a label, buttons and a text view (GTK+ and
+GLib/GIO demo); one of the buttons triggers a filter modifying the
+active layer (GEGL demo and GIMP API demo); all this while showing its
+own source code inside the text view (making it easy to inspect the code
+from within GIMP) and with a button sending you to the repository file
+(if you prefer to check out the last version, comfortably in your code
+editor).
 
 <figure>
 <img src="{attach}gimp-2.99.2-goat-exercises.jpg" alt="Goat Exercise in 5 languages"/>
@@ -454,21 +458,20 @@ it possible.
 
 ## Extensions
 
-Extensions are a new file format that is basically only a wrapper of
-data (brushes, splash screens, patterns, dynamics…) or plug-ins,
-associated with some metadata (name, description, screenshots, version,
-requirements…). The goal will be to allow plug-in developers to publish
-their work on a repository allowing anyone to search third-party
-plug-ins, install/uninstall, enable/disable and update them, all within
-GIMP.
+Extensions are a new file format that is simply a wrapper of data
+(brushes, splash screens, patterns, dynamics…) or plug-ins, associated
+with metadata (name, description, screenshots, version, requirements…).
+The goal will be to allow plug-in developers to publish their work on
+repositories for anyone to search third-party plug-ins,
+install/uninstall, enable/disable and update them, all within GIMP.
 
 The menu `Edit > Manage Extensions` shows the base dialog. In the
 "System Extensions" tab in particular, you will notice an "Official Demo
-Plug-ins" which is our first extension, which in fact bundles all the
-Goat Exercises plug-ins we talked about earlier. If you click the
-switch, you will notice after a restart (right now you have to restart
-GIMP to see the effect) that the menu category `Filters > Development >
-Goat Exercises`.
+Plug-ins" which is our first extension. It in fact bundles all the Goat
+Exercises plug-ins we talked about earlier. If you switch if off, you
+will notice after a restart (right now you have to restart GIMP to see
+the effect) that the menu category `Filters > Development > Goat
+Exercises` disappeared.
 
 <figure>
 <img src="{attach}gimp-2.99.2-goat-exercise-extension.png" alt="Goat Exercise as extension"/>
@@ -478,14 +481,14 @@ Goat Exercises`.
 </figure>
 
 We'll get back to talking about this feature after we've done more work
-on it. In particular, we will provide documentation how to create
+on it. In particular, we will provide documentation on how to create
 extensions. It is definitely something plug-in and resource creators
-should be look forward to, as it will help share their creations with
+should look forward to, as it will help share their creations with
 others.
 
 *Status*: still more work to do on the GIMP side, especially for
-communicating with repositories, and much more work for the official
-repository and website for extensions to be done.
+communicating with repositories, and much more work to be done for the
+official repository and the website for extensions.
 
 ## Space invasion
 
@@ -582,9 +585,9 @@ in this specific widget (again, we welcome theme contributors!).
 
 ## Refactoring
 
-While porting old features and implementing new features, a lot of side
-work has been done on the code structure. So many parts of the code base
-got refactored for better maintenance.
+While porting old features and implementing new ones, a lot of side work
+has been done on the code structure. Many parts of the code base got
+refactored for better maintenance.
 
 Even when some port is not done yet, ground work may have been prepared,
 such as the `GimpAction` interface to add a layer of abstraction to