[gimp-web] Update GIMP 2.99.2 news.

[Jehan <jehanp src gnome org>]

commit d84d117deb28658816292e3f685eb8a79d6ea3b8
Author: Jehan <jehan girinstud io>
Date:   Thu Nov 5 14:30:26 2020 +0100

    Update GIMP 2.99.2 news.
    
    Also getting of the third level section by moving the "Improvements"
    part down into "Plug-in API". After all this was the only section with 3
    levels and Alexandre was finding this a bit too much.

 .../.gitkeep                                       |   0
 .../gimp-2.10.22-2.99.2.jpg                        | Bin 0 -> 393154 bytes
 .../gimp-2.99.2-compact-spin-scale.png             | Bin 0 -> 79761 bytes
 .../gimp-2.99.2-goat-exercise-extension.png        | Bin 0 -> 45849 bytes
 .../gimp-2.99.2-goat-exercises.jpg                 | Bin 0 -> 589799 bytes
 .../gimp-2.99.2-import-policies-prefs.jpg          | Bin 0 -> 188818 bytes
 .../gimp-2.99.2-multi-layer-selection.png          | Bin 0 -> 76637 bytes
 .../gimp-splash-2.99.2.jpg                         | Bin
 .../index.md                                       | 321 +++++++++++++++------
 9 files changed, 226 insertions(+), 95 deletions(-)
---
diff --git a/content/news/2020/2020-06_GIMP-2.99.2_Released/.gitkeep 
b/content/news/2020/2020-11_GIMP-2.99.2_Released/.gitkeep
similarity index 100%
rename from content/news/2020/2020-06_GIMP-2.99.2_Released/.gitkeep
rename to content/news/2020/2020-11_GIMP-2.99.2_Released/.gitkeep
diff --git a/content/news/2020/2020-11_GIMP-2.99.2_Released/gimp-2.10.22-2.99.2.jpg 
b/content/news/2020/2020-11_GIMP-2.99.2_Released/gimp-2.10.22-2.99.2.jpg
new file mode 100644
index 00000000..98a0f111
Binary files /dev/null and b/content/news/2020/2020-11_GIMP-2.99.2_Released/gimp-2.10.22-2.99.2.jpg differ
diff --git a/content/news/2020/2020-11_GIMP-2.99.2_Released/gimp-2.99.2-compact-spin-scale.png 
b/content/news/2020/2020-11_GIMP-2.99.2_Released/gimp-2.99.2-compact-spin-scale.png
new file mode 100644
index 00000000..a5e967d4
Binary files /dev/null and 
b/content/news/2020/2020-11_GIMP-2.99.2_Released/gimp-2.99.2-compact-spin-scale.png differ
diff --git a/content/news/2020/2020-11_GIMP-2.99.2_Released/gimp-2.99.2-goat-exercise-extension.png 
b/content/news/2020/2020-11_GIMP-2.99.2_Released/gimp-2.99.2-goat-exercise-extension.png
new file mode 100644
index 00000000..0c2b6dfa
Binary files /dev/null and 
b/content/news/2020/2020-11_GIMP-2.99.2_Released/gimp-2.99.2-goat-exercise-extension.png differ
diff --git a/content/news/2020/2020-11_GIMP-2.99.2_Released/gimp-2.99.2-goat-exercises.jpg 
b/content/news/2020/2020-11_GIMP-2.99.2_Released/gimp-2.99.2-goat-exercises.jpg
new file mode 100644
index 00000000..a3731aae
Binary files /dev/null and b/content/news/2020/2020-11_GIMP-2.99.2_Released/gimp-2.99.2-goat-exercises.jpg 
differ
diff --git a/content/news/2020/2020-11_GIMP-2.99.2_Released/gimp-2.99.2-import-policies-prefs.jpg 
b/content/news/2020/2020-11_GIMP-2.99.2_Released/gimp-2.99.2-import-policies-prefs.jpg
new file mode 100644
index 00000000..0a23f967
Binary files /dev/null and 
b/content/news/2020/2020-11_GIMP-2.99.2_Released/gimp-2.99.2-import-policies-prefs.jpg differ
diff --git a/content/news/2020/2020-11_GIMP-2.99.2_Released/gimp-2.99.2-multi-layer-selection.png 
b/content/news/2020/2020-11_GIMP-2.99.2_Released/gimp-2.99.2-multi-layer-selection.png
new file mode 100644
index 00000000..44eb2b9d
Binary files /dev/null and 
b/content/news/2020/2020-11_GIMP-2.99.2_Released/gimp-2.99.2-multi-layer-selection.png differ
diff --git a/content/news/2020/2020-06_GIMP-2.99.2_Released/gimp-splash-2.99.2.jpg 
b/content/news/2020/2020-11_GIMP-2.99.2_Released/gimp-splash-2.99.2.jpg
similarity index 100%
rename from content/news/2020/2020-06_GIMP-2.99.2_Released/gimp-splash-2.99.2.jpg
rename to content/news/2020/2020-11_GIMP-2.99.2_Released/gimp-splash-2.99.2.jpg
diff --git a/content/news/2020/2020-06_GIMP-2.99.2_Released/index.md 
b/content/news/2020/2020-11_GIMP-2.99.2_Released/index.md
similarity index 65%
rename from content/news/2020/2020-06_GIMP-2.99.2_Released/index.md
rename to content/news/2020/2020-11_GIMP-2.99.2_Released/index.md
index 7180e488..20206f55 100644
--- a/content/news/2020/2020-06_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-10-25
+Date: 2020-11-05
 Category: News
 Authors: Wilber
 Slug: gimp-2-99-2-released
@@ -35,29 +35,35 @@ of redevelopping them on GTK2) or some client-side window decorations on
 various dialogs. But the esthetical differences are far from being the
 main appeal of GTK3.
 
-TODO: maybe a screenshot GIMP 2.10.22 and GIMP 2.99.2 side by side?
+<figure>
+<img src="{attach}gimp-2.10.22-2.99.2.jpg" alt="GIMP 2.10.22 and 2.99.2 interfaces side by side"/>
+<figcaption>
+<em>Left: GIMP 2.10.22 - Right: GIMP 2.99.2</em>
+</figcaption>
+</figure>
 
 ### High pixel density displays
 
-One of the main issues of GTK2 for screens used these days was the
-absent support for high pixel density displays (e.g. small screens with
-high resolution or big screens with extremely high resolution) which
-become more widespread nowadays, especially among graphics
-professionals. GIMP 2.10 came with some partial workaround which was
-acceptable only on some very limited cases but was not holding
-expectation for intense usage of the software.
+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 become more widespread nowadays,
+especially among graphics professionals. GIMP 2.10 came with some
+partial workaround which was acceptable only on some limited cases but
+was not holding expectation for intense usage of the software.
 
 GTK3 brings proper support to GIMP whose whole graphical interface will
 follow your system-set scale settings.
 
+*Status*: basically done (except if we forgot any custom widgets).
+
 ### Improved input devices support
 
 By "input device", we are mostly talking about drawing tablets or
-pen displays. In GIMP 2, you had to plug the tablet before starting
-GIMP, enable each new device explicitly in the settings and, worse,
-unplugging the tablet could lead to unstability of the software (though
-this issue got mostly worked around on GTK2 by GIMP developers within
-the 2.8 branch release period).
+pen displays. In GIMP 2, their support had many shortcomings: you had to
+plug the tablet before starting GIMP, enable each new device explicitly
+in the settings and, worse, unplugging the tablet could lead to
+unstability of the software (though this issue got mostly worked around
+on GTK2 by GIMP developers within the 2.8 branch release period).
 
 GIMP 3 (hence this first development release) brings hotplug support,
 which basically means: start GIMP, plug your tablet, done. You are ready
@@ -82,11 +88,10 @@ GIMP 3 will come with specific gesture support. This is not to say that
 we don't want it, and we welcome any patches from anyone willing to make
 it one's priority.
 
-*Work-in-progress*: more work needs to be done to simplify device
-support as a lot of legacy features are either not needed anymore
-nowadays or can be better presented. Some Wayland-specific handling may
-be in order as well, since Wayland brings news abilities to input
-devices.
+*Status*: some work needs to be done to simplify configuration dialog as
+support of legacy features are either not needed anymore nowadays or can
+be better presented. Some Wayland-specific handling may be in order as
+well, since Wayland brings news abilities to input devices.
 
 ### Theming
 
@@ -103,17 +108,23 @@ remember you also had to switch the symbolic icon themes manually. This
 won't be necessary anymore as symbolic icons will be recolored according
 to your theme.
 
-Finally a same theme may propose both a dark and light variant so the
-Theme preferences shows a "*Use dark theme variant if available*"
-checkbox. Similarly icon themes may propose symbolic and color icons.
-Once again our Icon Theme preferences provides a "*Use symbolic icons if
+Finally "dark theme" is a core concept of GTK3, which means for instance
+that even window decorations get recolored as can be seen in the
+screenshot above.
+Also a same theme may propose both a dark and light variant so the Theme
+preferences shows a "*Use dark theme variant if available*" checkbox.
+Similarly icon themes may propose symbolic and color icons.  Once again
+our Icon Theme preferences provides a "*Use symbolic icons if
 available*" checkbox allowing you to indicate your prefered style.
 
-*(No) Work-in-progress*: you will notice that GIMP 2.99.2 only proposes
-you the "System" theme, which basically means no theme (or rather, that
-GIMP follows your system theme, as the name implies). Something we want
-before releasing GIMP 3.0 is default custom theme with a neutral
-dark/light variant as well as a neutral middle-gray custom theme.
+*Status*: waiting for theme contributors.
+
+On core side, there is not much more to do. Yet you will
+notice that GIMP 2.99.2 only proposes you the "System" theme, which
+basically means no theme (or rather, that GIMP follows your system
+theme as the name implies). Something we want before releasing GIMP 3.0
+is a default custom 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 are solely meant to be
 pretty. Yet advanced graphics work requires a neutral gray theme in
 order not to pollute your color perception. This is the main reason why
@@ -151,6 +162,9 @@ for GIMP 3.0, because we still require some features of the GTK file
 dialog, but it may happen later with a planned redesign for improved
 export process.
 
+*Status*: a few blocking bugs in particular require attention. We
+welcome contributions.
+
 ## Multi-layer selection
 
 One of the major annoyances of layer management in GIMP until now was
@@ -167,18 +181,23 @@ example of close artist-developer collaboration project as every feature
 was carefully designed by discussions and have actually been tested in
 production ever since March 2020.
 
-TODO: add screenshot
+<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>
+</figcaption>
+</figure>
 
-Layers dockable is now fully multi-selection aware, using the usual
-interaction to select several layers (`Shift+click` for selecting a
-range of layers, `Ctrl+click` for (un)selecting non-contiguous layers).
-And organizational operations now work on all selected layers, i.e. that
-you can move, reorder, delete, duplicate, merge (and more…) all selected
-layers at once.
+The Layers dockable is now fully multi-selection aware, using the usual
+interaction for multi items selection (`Shift+click` for selecting a
+range of layers and `Ctrl+click` for selecting or unselecting
+non-contiguous layers). Organizational operations now work on all
+selected layers, i.e. that you can move, reorder, delete, duplicate,
+merge (and more…) all selected layers at once.
 
 Several tools now also work on multiple selected layers. For instance
 all transform tools (move, rotation, scale, perspective, unified
-transform…) works on all selected layers (in addition to the existing
+transform…) will transform all selected layers (in addition to the existing
 layer links with the "chain" icon). You may also crop several layers at
 once or copy-paste merged layers' projection. Even the Color Picker tool
 can now pick merged color from several layers (some kind of partial
@@ -191,9 +210,9 @@ report](https://www.patreon.com/posts/report-on-for-in-37266151),
 containing many images and descriptions. There is of course even more
 which you can discover yourself!
 
-*Work-in-progress*: the multi-layer selection work is ongoing. Some
-parts are still expecting a single layer and need to be ported to the
-new release, and it is not impossible that some features may even be
+*Status*: the multi-layer selection work is still ongoing. Some parts
+are still expecting a single layer and need to be ported before
+release, and it is not impossible that some features may even be
 broken (that's why we have development releases, to discover bugs!).
 
 Moreover we may extend the multi-item selection ability to paths and
@@ -208,8 +227,6 @@ discovery of mistake editing are the main design issues to solve).
 
 ## Plug-in API
 
-### Improvements
-
 The plug-in API got many improvements, though we also took care not to
 break too widely the existing API when not necessary. It is estimated
 that a single-file plug-in working for the GIMP 2.10 series can be
@@ -225,7 +242,7 @@ replacement](https://gitlab.gnome.org/GNOME/gimp/-/blob/master/devel-docs/GIMP3-
 You can already do this part of the port while still targetting GIMP
 2.10.x versions.
 
-#### Object API
+### Object API
 
 Among the noteworthy changes, we moved away from object IDs to real
 objects. In particular in GIMP 3, `GimpImage`, `GimpItem`,
@@ -248,13 +265,13 @@ their own object model. Hence duplicating a `GimpImage` named for
 instance `img` in Python 3 can be done with the quite pythonic API `img2
 = img.duplicate()`.
 
-*Work-in-progress*: finally it will also allows to easily use object
+*Status*: object port is basically done. We also want to use object
 signalling, which is a work-in-progress and should eventually allow to
 connect signal handlers directly on objects, in order to manage events
 from the core application (something impossible in GIMP 2, except by
 regular polling).
 
-#### GIO usage for file handling
+### 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.
@@ -270,23 +287,25 @@ Working with a `GFile` makes internal representation transparent and
 file handling robust.
 
 The second big advantage is that it means all such API gains any ability
-of your local GIO modules, in particular loading or saving from/to
-remote locations (even possibly through secure channels like HTTPS).
+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
 plug-in developers as well in GIMP 3.0.
 
-*Work-in-progress*: for binding languages through GObject Introspection,
-it is to be noted that they also have full access to GLib/GIO API so
-they are able to create GFile from paths or URI without any problem. For
-legacy manual bindings, such as the `script-fu` (Scheme) one, we are
-working on it (a patch even already exists, but needs to be reviewed).
+*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.
 
-#### Plug-in declaration
+### Plug-in declaration
 
-The biggest changes have been done in the API to declare your plug-in.
+Some major changes have been done in the API to declare your plug-in.
 This is now done by subclassing the `GimpPlugIn` class and overriding
 some methods to list and document the created plug-in procedures. We
 made a much cleaner and explicit API than the previous one which should
@@ -295,20 +314,20 @@ 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 to 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.
+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.
 
 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 the ground work towards such feature) since we will be able to
+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).
 
-*Work-in-progress*: though the main part of this API is done, more needs
-to happen before the release, and in particular we are still tinkering
+*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.
 
 ### Bindings
@@ -324,17 +343,18 @@ can now be scripted (additionally to C and C++ of course) with:
 * Lua
 * Vala
 
-One of the main difference with how GIMP used to be scriptable, with
-Python 2 notably, is that an additional layer API is not needed anymore.
+One of the main differences with how GIMP used to be scriptable, with
+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 mean that plug-ins in Python 3
-or Javascript for instance will have the same possibilities as C
-plug-ins. This is a bright new world for GIMP plug-in developers!
+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!
 
-This means in particular that the API is basically the same for all
-these languages, except for language idiosyncracies.
+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:
 
@@ -374,24 +394,25 @@ replaced by a Python list):
 Gimp.edit_copy([drawable1, drawable2, drawable3])
 ```
 
-One of the other main advantages is that non 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 GIMP. For instance a plug-in
-can have access to the full GTK API as well, or 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
-API for instance, which could not manipulate pixels with GEGL.
-
-*Work-in-progress*: of course some people are regretting the facilities
-provided by the specific Python binding, such as automatic dialog
-creation. These are things which we are working on right now and should
-be available for the next development release. The best part is that
-such API will be done on the main API, hence available to all bindings,
-not just Python or Scheme.
+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
+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
+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
-in every available binding, we should provide them in the main API so
-that every developer can enjoy them, whatever your prefered language.
+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
@@ -415,12 +436,23 @@ 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).
 
+<figure>
+<img src="{attach}gimp-2.99.2-goat-exercises.jpg" alt="Goat Exercise in 5 languages"/>
+<figcaption>
+<em>The 5 versions of the Goat Exercise plug-in in Python 3, Javascript, Lua, C and Vala</em>
+</figcaption>
+</figure>
+
 These plug-ins are quite important as we are planning to improve the
 plug-in ecosystem with GIMP 3. They are the first step of
 "self-documenting demo plug-ins" (while doing something a bit more
 exciting that a bare "Hello World").
 
-### Documentation
+*Status*: current code of the Goat Exercise is not always up-to-date
+with the most recent API yet as it is a moving target. These will be
+updated before release.
+
+### Developer documentation
 
 We have started to write down some documentation regarding plug-in
 development in GIMP 3, and will progressively start to publish some
@@ -430,6 +462,9 @@ website who have been abandonned for too many years.
 We really hope that GIMP 3 will breath some new life into the GIMP
 plug-in ecosystem!
 
+*Status*: still early idea stage of this project and we welcome more
+contributors on this side to make it possible.
+
 ## Extensions
 
 Extensions are a new file format which is basically only a wrapper of
@@ -448,12 +483,23 @@ 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`.
 
+<figure>
+<img src="{attach}gimp-2.99.2-goat-exercise-extension.png" alt="Goat Exercise as extension"/>
+<figcaption>
+<em>The Goat Exercises are themselves a system extension.</em>
+</figcaption>
+</figure>
+
 We will explain further this feature when we will have developed more,
 and in particular we will provide appropriate documentation for
 extension creation.
 It is definitely something plug-in and resource creators should look
 forward to, as it will help share your creations with others.
 
+*Status*: still more work to do on GIMP side, especially for
+communicating with repositories, and much more work for the official
+repository and website for extensions to be done.
+
 ## Space invasion
 
 "*Space invasion*" is the internal code name for the work originally
@@ -475,6 +521,10 @@ Some of the improvements of this work have already been progressively
 backported to various GIMP 2.10.x releases, but GIMP 3.0 should be the
 culminating release where we hope to get this fully right.
 
+*Status*: the development branch is much more advanced on this topic
+than the 2.10 series, but some more work need to be done. Various
+aspects of GIMP still mostly expect or display sRGB only values.
+
 ## Render caching
 
 GIMP 3 now has a render cache that keeps the result of scaling, color
@@ -488,9 +538,83 @@ mipmap level instead of linear or box filtering. This gives a slight and
 permanent boost to painting and all updates. We have a few ideas to improve this
 further (like reblitting in high quality after a timeout).
 
+*Status*: done.
+
+## Improved import policies
+
+**Color Profile Policy** now exposes a new choice "*Convert to Preferred
+Profile*" and the import dialog default "Convert" action will convert
+the image to the preferred profile (if any was set, otherwise it falls
+back to the built-in profile). Converting to the built-in profile will
+be still available as secondary action.
+This allows people who want to always work with a given profile to be
+able to set up their prefered workflow as soon as import is done.
+
+Moreover a new **Metadata Rotation Policy** is exposed in the
+Preferences dialog, next to the *Color Profile Policy* (in page
+`Preferences > Image Import & Export`) with 3 options: "Ask what to do",
+"Discard metadata without rotating" and "Rotate the image then discard
+metadata".
+
+<figure>
+<img src="{attach}gimp-2.99.2-import-policies-prefs.jpg" alt="Import Policies"/>
+<figcaption>
+<em>Updated Color Profile policy and new Metadata rotation policy</em>
+</figcaption>
+</figure>
+
+The metadata rotation policy used to be handled API-side, with a dialog
+generated by `libgimpui` and saved in a global parasite. The whole
+logics and GUI has been moved as core logics, similar to the "Color
+Profile Policy". This implies that plug-ins don't even need to handle
+this as this will happen as specified by the user automatically on every
+new import.
+
+*Status*: done.
+
+## Compact sliders
+
+The compact spin scale was introduced in [GIMP
+2.10.18](https://www.gimp.org/news/2020/02/24/gimp-2-10-18-released/#compact-sliders).
+In the 2.10 series, it was left as an optional feature which could be
+deactivated in the Preferences.
+
+In GIMP 3, these have been made the only variant (no preference
+anymore).
+
+<figure>
+<img src="{attach}gimp-2.99.2-compact-spin-scale.png" alt="Compact slider"/>
+<figcaption>
+<em>New compact slider is now default and only option</em>
+</figcaption>
+</figure>
+
+Note that it has been noted that the bright blue color may not be the
+best idea but the color in this screenshot does not reflect a color
+choice, only the underlying system theme during screenshot.
+This widget actually uses `GtkProgressBar` colors by default. Therefore
+this can be updated in a custom theme by changing `GtkProgressBar`
+colors or only the colors in this specific widget (cf. our need for
+theme contributors).
+
+*Status*: done.
+
 ## Refactoring
 
-TODO
+While porting old features and implementing new features, a lot of side
+work has been done on the code structure obviously. So 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
+`GtkAction` (preparing us to actually move away from it at a later
+point which is one of the main remaining big ports for the move to GTK3).
+
+Many other parts are constantly remodeled and improved as a constant
+background work.
+
+*Status*: refactoring is always in progress, always was, always will.
+This is a developer's continuous task!
 
 ## Packaging
 ### Beta Flatpak available
@@ -521,6 +645,10 @@ flatpak make-current --user org.gimp.GIMP beta
 flatpak make-current --user org.gimp.GIMP stable
 ```
 
+Some people also created shortcuts running the explicit command `flatpak
+run org.gimp.GIMP//beta` (respectively `stable`) as workaround to get
+icons for both versions.
+
 ### Windows
 
 As usual, we provide a Windows installer for GIMP, you will find it on the
@@ -543,13 +671,15 @@ If you are interested, we suggest to get in touch with us on our
 
 ## What's next
 
-As you can see, a lot has been done. Actually the main part of each
-task has been mostly done on all needed areas. Now what remains is the
-final stroll. This is however not such an idle walk in the park, as the
-last decisions and attention to details is always the most difficult
-part. We want to release a rock-solid GIMP 3 and needs to take a lot of
-care to all the small little things. This is where we are now and why we
-are releasing this first development version.
+As you can see, a lot has been done (the
+[`NEWS`](https://gitlab.gnome.org/GNOME/gimp/-/blob/4f201556967d9e7c868601698e9e3d957c1c27ea/NEWS#L46)
+file will also give a bit more details). Actually the main part of most
+task has been mostly done. Now what remains is the final stroll. This is
+however not such an idle walk in the park, as the last decisions and
+attention to details is always the most difficult part. We want to
+release a rock-solid GIMP 3 and needs to take a lot of care to all the
+small little things. This is where we are now and why we are releasing
+this first development version.
 
 This [development
 report](https://www.patreon.com/posts/what-remains-to-40087754) lists
@@ -557,9 +687,10 @@ pretty accurately all the remaining steps, and you'll notice how it
 actually follows quite well the changes in GIMP 2.99.2. The API part,
 though going unnoticed to many users, is probably the major part which
 we must absolutely get right before release since our API is meant to be
-stable. Once we have it done, we will want to keep 3.0.0 functions
-unchanged unless absolutely necessary (i.e. unless we discover bugs
-which made a function useless). This will likely take a lot of our time.
+stable. Once we have it done, we will want to keep existing interfaces of
+`libgimp` 3.0.0 functions unchanged unless absolutely necessary (i.e.
+unless we discover bugs which made a function useless). This will likely
+take a lot of our time.
 
 There are definitely other parts as well where any help would be
 appreciated. As said, we are at a step with a lot of little details and