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

[Jehan <jehanp src gnome org>]

commit 85402e88d1f30197b11f388b0b6a6646af892888
Author: Jehan <jehan girinstud io>
Date:   Thu Feb 24 00:22:20 2022 +0100

    content: update GIMP 2.99.10 news.
    
    All this was written in one go with barely re-reading. I'll do the
    re-reading and cleaning tomorrow.
    
    Also I'll have to add proper screenshots because many of the features
    and changes presented here would be a lot more understandable with
    images.

 .../2022/2022-02_GIMP-2.99.10_Released/index.md    | 297 ++++++++++++++++++++-
 1 file changed, 296 insertions(+), 1 deletion(-)
---
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 1c5a81dd..b567dcb5 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
@@ -138,26 +138,321 @@ GTK3 and experiencing similar issues.
 
 ## 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
+dynamics. Obviously this neutral dynamics has been removed from the list
+of installed data.
+
+It allows to switch dynamics painting in a single click without having
+to remember which dynamics you were using.
+
+For advanced user, we also set up the new action
+"context-dynamics-toggle". It means you can create a shortcut to switch
+the dynamics painting stat for even faster work.
+
 ## New feature for Line Art mode of bucket fill tool
 
+We have 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 not necessarily final as naming this was pretty hard.
+
+Anyway here is what it does: when you select the "Layer above/below the
+selected one" as source, the selected layer is not used as line art
+source (as the title says). Yet with this option, you add the ability to
+paint with your fill color directly in the selected layer and union this
+data 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.
+
+One of the main usage could be to set the "Maximum gap length" to 0,
+which totally disable the line art closure computation, which means 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 it comes into play.
+
 ## Going further with our compact slider widget
 
+Our compact slider was only available to core code until recently. It
+means that all plug-ins in particular could not use 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, all
+the while maximizing the space.
+
+A few of our official plug-ins already make use of it now.
+
+Additionally our default `System` theme made it even more compact,
+because there were some complaints that this said *compact* slider was
+not compact enough!
+
 ## Official plug-ins
 ### PSD
+
+As often lately, our PSD plug-in got some love to widen our support
+abilities:
+
+* new support for loading 16-bit per channel CMYK images.
+* new support for files in LAB colorspace.
+* 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
+  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
+  layer group. Doing this results in the same image as the PSD
+  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
+  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
+  anymore.
+
 ### JPEG-XL
+
+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
+  precision images).
+* New very fast export settings: thunder and lightning (fastest).
+* Compression slider is disabled for lossless.
+
 ### Microsoft Windows Cursor (`.cur`)
-### Screenshot on Windows
+
+GIMP is now able to load and export Microsoft Windows Cursors, including
+the ability to read at import, pass on and edit at export the hot spot
+location for each cursor in the file.
+
+### Screenshot
+
+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
+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.
+
+On **Windows**, the Screenshot plug-in finally get a "cursor capture"
+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
+settings. This heuristic didn't agree with everyone's logic.
+
+Also it was going against the settings storage which are now a basic
+feature of most plug-ins.
+
+So we decided to just drop this heuristic and leave the user completely
+responsible for chosing the bit-depth they wish.
+
 ### Deprecating `help-browser` and `webpage` plug-ins
 
+We have 2 plug-ins depending on the WebkitGTK library:
+
+1. `help-browser`: for displaying the html docs. Nowadays every desktop
+   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
+   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
+   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.
+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
+in any positive way, we are not recommending packagers to build these
+anymore.
+
 ## Build and documentation
 ### Icon theme handling and refactoring
+
+Our icon theme handling code was a bit of a mess because of too many
+build cases, so we refactored it:
+
+* We now use the exact same list for the Color and Symbolic icon themes,
+  both in their SVG and PNG variants.
+* The PNG variants for both themes are now fully generated from the SVG
+  files instead of duplicating everything and risking strange bugs with
+  specific build combinations.
+* 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.
+
+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
+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
+the PNG variant for now. It is suboptimal and on platforms where
+`librsvg` is not a problem, we definitely advise to use SVG icons. But
+at least the option exists.
+
+Note though that there is another case where we depend on `librsvg`: the
+SVG import plug-in and this one had been made a mandatory one. We are
+not changing this because as graphics professionals, we consider that
+even in a raster program, you need to be able to import SVG nowadays.
+This format is simply a professional standards now and not supporting it
+seems absurd.
+Yet we understand if it is a problem on some platforms so, packagers,
+feel free to comment out the SVG plug-in if really this is a problem to
+you, as we have been told. It should be quite easy to achieve.
+
 ### Clang-format check in Continuous Integration
+
+A new `.clang-format` file was added to our repository and now every
+merge request will trigger a CI job to verify coding-style of your
+change.
+
+Now to be perfectly fair, we are not completely happy with the check
+results, which is why the job failures are not fatale, mostly
+informational. Let's say this is a first step, hoping this coding style
+check will get better.
+
 ### `flatpak-release` tool to test older versions easily
+
+Flatpak has limitations but also quite some interesting features. One of
+them is the ability to install older versions of the package. 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.
+
+This is where this tool comes from:
+
+```
+$ tools/flatpak-releases  -h
+Usage: ./flathub-releases [--beta] [--system] [-X] [org.example.app]
+
+List all flatpak builds stored on Flathub or GNOME repository.
+The builds for org.gimp.GIMP are looked up by default unless
+you provide explicitely another AppStream ID.
+
+Adding a -X number as option install the numbered release
+instead of listing them.
+
+Options:
+
+-0: install the last build.
+-1: install the previous build.
+-2: install the before-previous build (and so on).
+
+--beta: list or install a beta release
+--nightly: list or install a nightly release
+--system: install as system flatpak (default to user install)
+```
+
+So say I want to know all the beta release which Flathub has stored:
+
+```
+TODO: after flatpak update.
+```
+
+Now say I want to install the one where I released GIMP 2.99.6 for a
+test:
+
+```
+TODO: after flatpak update.
+```
+
+Done. In 2 commands and less than a minute, I am now able to run our
+GIMP 2.99.6 flatpak beta package which was 4 packages ago.
+
+This command allows me to do this for the stable, the beta and the
+nightly packages.
+
+
 ### New contributor documentation
 
+Our developer document was a bit sparse and not too maintained these
+days, so a new version is starting to get written. It's still widely
+incomplete and some part are based on older docs which might be
+outdated, or at least would deserve a review. In any case, work is in
+progress.
+
+For anyone wishing to contribute, [this is where you should
+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:
+
+* `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()`
+* Removed functions:
+  + `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))
+* 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()`
+* 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).
+
+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.
+
 ## Team news
 
 On our main source repository, "*reporter*" access (allowing to triage