GNOME.org
 

[gimp-web] Update GIMP 2.99.4.

commit 80ba5ecfb34307d62275123c60552c7cee0a1b12
Author: Jehan <jehan girinstud io>
Date:   Fri Dec 25 22:11:59 2020 +0100

    Update GIMP 2.99.4.

 .../2020/2020-12_GIMP-2.99.4_Released/index.md     | 165 ++++++++++++++-------
 1 file changed, 111 insertions(+), 54 deletions(-)
---
diff --git a/content/news/2020/2020-12_GIMP-2.99.4_Released/index.md 
b/content/news/2020/2020-12_GIMP-2.99.4_Released/index.md
index 4e3082c2..c1e0cffd 100644
--- a/content/news/2020/2020-12_GIMP-2.99.4_Released/index.md
+++ b/content/news/2020/2020-12_GIMP-2.99.4_Released/index.md
@@ -13,17 +13,22 @@ Release highlights:
 
 - Usability fixes across various parts of GIMP
 - New Paint Select tool in the playground
-- New generic metadata support API for saving
+- New generic dialog generation and metadata support API for export
+  plug-ins
 - Multi-threaded JPEG2000 decoding
 - Initial documentation on porting plug-ins to 3.0
 
 <figure>
+<a href="{attach}2020-gimp-2-99-4-xmas.jpg">
 <img src="{attach}2020-gimp-2-99-4-xmas.jpg" alt="GIMP 2.99.4 present for Christmas! by Aryeom, CC by-sa"/>
+</a>
 <figcaption>
 <em>GIMP 2.99.4 present for Christmas! by <a href="https://film.zemarmot.net";>Aryeom</a>, Creative Commons 
by-sa 4.0</em>
 </figcaption>
 </figure>
 
+[TOC]
+
 # Usability fixes
 ## Slider widget
 
@@ -35,7 +40,7 @@ usage.
 The first issue was the ability to edit the scale value numerically
 (i.e. by inputting numbers on keyboard) without also triggering a value
 change (with main button click). This was actually possible with a
-middle click which was hardly discoverable. Therefore it is now possible
+middle click which is hardly discoverable. Therefore it is now possible
 to pinpoint-click the displayed numbers. This action will only focus the
 text input (by default entirely selecting the existing value as is
 common when focusing text entries). You can still click-edit the value
@@ -43,31 +48,31 @@ from everywhere in the widget, except exactly on the numbers.
 
 The second issue was providing cursor change, meant to help feature
 discovery:
+
 * The top-arrow cursor came from a time where this widget had 2 areas, a
-  top and bottom area, and doesn't really mean anything anymore on the
+  top and bottom area. It doesn't really mean anything anymore with the
   current interaction. We replaced it by a common "*grab*" cursor as
   specified in the CSS specification. This becomes a "*grabbing*" cursor
   when a click'n drag is in progress.
 * When the pointer is hovering the text area, it becomes a "*text*"
   cursor instead, hence advertizing the fact that a click here would
-  produce a different action.
+  start text edition.
 * Finally when holding the `Shift` modifier key, the cursor will become
   an horizontal resize cursor ("*col-resize*" in CSS specification),
   hence advertizing the ability for smaller relative resizing (an action
   also available with the third button, usually `right-click`).
 
-
 <figure>
 <img src="{attach}gimp-2.99.4-slider-cursors.png" alt="GIMP 2.99.4: usability improvements on the slider 
widget"/>
 <figcaption>
-<em>GIMP 2.99.4: new cursors on the slider to grab, do small updates or text-only edit</em>
+<em>GIMP 2.99.4: new cursors on the slider to grab, when grabbing, do small updates or text-edit</em>
 </figcaption>
 </figure>
 
 ## Multi-layer selection
 
-Multi-item selection in the `Layers` dockable comes with a few generic
-key combinations, common multiple selection interactions such as:
+Multi-item selection in the `Layers` dockable comes with common key
+interactions for multiple selection such as:
 `Shift-click` for range selection or `Ctrl-click` for selection
 modification. These interactions clashed with some features we had on
 layer and mask thumbnails. For instance one could end up modifying a
@@ -89,15 +94,15 @@ taken:
   clashes (e.g. `Ctrl-click` should not trigger both the `Ctrl-click`
   and simple `click` actions).
 * Actions done when clicking a thumbnail with modifiers do not change
-  the selection anymore and will now operate on the clicked layer or
-  mask, not on selected layers/masks. This makes these actions more
-  useful as they are not redundant anymore.
+  the selection and will now operate on the clicked layer or mask, not
+  on selected layers/masks. This makes these actions more useful as they
+  are not redundant anymore.
 
 The concrete consequential changes are as follow:
 
-* `Ctrl-click` on a mask thumbnail to enable/disable it is changed to
-  `Alt-Ctrl-click`. The other mask action, `Alt-click` for showing
-  the mask, stays the same.
+* `Ctrl-click` on a mask thumbnail to enable/disable the layer mask is
+  changed to `Alt-Ctrl-click`. The other mask action, `Alt-click` for
+  showing the mask, stays the same.
 * `Shift-click` and `Ctrl-click` actions on a layer thumbnail to
   respectively add (with last used values) or remove a layer mask have
   been removed. Indeed all `Alt+` combinations are already taken on
@@ -109,8 +114,8 @@ The concrete consequential changes are as follow:
   discoverability on random clicks) and these "*Add/Remove mask*"
   actions were much newer (2.10.0) anyway.
 * Thumbnail popups on long click do not happen anymore when any modifier
-  is hold, hence removing a distraction when this was obvioulsy not what
-  we were looking for.
+  is being held, hence removing a distraction when this was obvioulsy
+  not what we were looking for.
 
 ## Input Devices dialog
 
@@ -129,8 +134,8 @@ dialog. This is a work we started earlier and continued for GIMP 2.99.4.
   rarely (only on some specific drawing styluses in the market, even
   uncommon among professionals). The dialog will now only list the axes
   returned by the driver (note that even this list may still show more
-  than a specific device actually has because drivers are sometimes
-  over-listing, but it is still much closer to reality).
+  than what a specific device really has because drivers are sometimes
+  over-listing, yet it is still much closer to reality).
 * When a device is connected, the names of the axes will also be the
   ones as listed by the backend, which will get us closer-to-reality
   names. Typically the `X` axis for a graphics tablet will be `Abs. X`
@@ -143,7 +148,7 @@ dialog. This is a work we started earlier and continued for GIMP 2.99.4.
   allowing you to directly work on the curve, without unecessarily
   clicks.
 
-**Call for inputs**:
+**Call for user input**:
 
 There are a few puzzling settings in this dialog and we would welcome
 input from anyone who had actual needs for it. How were you using any of
@@ -153,13 +158,12 @@ these features? Which OS? What was the goal?
   actually removed this list back in 2.99.2. Based on tests, code
   research and discussion with Carlos Garnacho, our local GTK and input
   device expert, we came to the conclusion that the "Keys" concept was
-  tied to "keyboard" devices (a type of devices specifically which has
-  always been filtered out of this listing, at least since 2.8 and
-  probably before) and is meaningless on "pointer" devices (mice,
-  touchpads, graphics tablets…). Yet here was the option! Maybe it
-  actually had a hidden usage to someone, someday? If this is your case,
-  please explain us so that we can think of a way to restablish the
-  feature with an understandabble interface.
+  tied to "keyboard" devices (a type of devices not shown in this
+  dialog) and is meaningless on "pointer" devices (mice, touchpads,
+  graphics tablets…). Yet here was the option! Maybe it actually had a
+  hidden usage to someone, someday? If this is your case, please explain
+  us so that we can think of a way to restablish the feature with an
+  understandable interface.
 * The "Axes" list has the ability to set the "axis use" for a given
   axis (the little numbers next to each axis). Yet we never managed to
   do anything with it. This looks mostly either broken or meaningless.
@@ -191,11 +195,10 @@ understandable hence useful to more people.
 ## Better device defaults
 
 As explained in the 2.99.2 release, GIMP 3 has a much better input
-device detection as well as hotplug detection. So it became much more
-important to provide reasonable defaults when a new device is detected
-so that people are able to immediately check it works correctly.
-In particular for graphics tablets, people want to test immediately that
-pressure is supported.
+device detection as well as hotplug detection. So it became important to
+provide reasonable defaults when a new device is detected so that people
+are able to immediately check it works correctly. In particular for
+graphics tablets, people expect pressure to work from scratch.
 
 For these reasons, here are the tools enabled by default the first time
 you plug a device:
@@ -231,8 +234,8 @@ For Korean "한" (han) was chosen (apart from being the first syllable in
 "Hangeul", the name of the Korean writing system) firstly because it is a
 syllable with two consonnants, which gives good indications on stylistic
 choices, and secondly because of the circle shape in 'ㅎ' (hieut) but
-also its small *hat* which has many stylistic variants and is therefore
-also quite a good hint of stylistic choices made by a font designer.
+also its small *hat* have many stylistic variants and are therefore also
+quite good hints of stylistic choices made by a font designer.
 
 As for "あ", it is the first *kana* in the hiragana syllabary, which is
 one of the main component of the Japanese writing system.
@@ -269,7 +272,8 @@ Yet we expect it to be quite efficient and fast in the end.
 ## What about the Foreground Select tool?
 
 Some people might be wondering about the Foreground Select tool, which
-looks from a quick look as very similar.
+looks from a quick look very similar to the new experimental Paint
+Select tool.
 This quote from Thomas might explain the difference:
 

Foreground select uses a matting algorithm : its goal is to provide an

@@ -304,10 +308,11 @@ historically comes with a "procedure" (which can be called from the core
 but also from other plug-ins through the `PDB` protocol), with
 parameters and 3 run methods: interactively, non-interactively and with
 last values. The non-interactive and with last values run methods
-imply known parameters (given by the caller), but an "interactive" run
-implies to ask for these parameters, usually with added logics.
+imply known parameters (given by the caller or previous calls), but an
+"interactive" run implies to ask for these parameters in a GUI, usually
+with added logics.
 
-Until now, this always needed specific GUI code. We now added some new
+Until now, this always needed specific GUI code. We now added new
 functions for easy dialog generation from the procedure parameters. In
 simplest case, you could therefore generate a full blown plug-in dialog
 in less than 5 lines.
@@ -317,11 +322,17 @@ every displayed property in a plug-in dialog has a unique mnemonic. This
 is a very useful feature for usability and accessibility, for people who
 mostly use keyboard navigation.
 
+Similar ability used to be available on some specific bindings (Python
+and Scheme). The new functions will be available for all plug-ins (i.e.
+C/C++ plug-ins, but also for GObject-Introspected bindings, for instance
+in Python 3, Javascript, Vala or Lua). Moreover the customizability is
+much more powerful.
+
 ## New generic metadata support API for exporting
 
 With the plug-in dialog generation, we also special-cased some feature
 for export plug-ins. In particular, we tried to rework some of the
-metadata logics and common points accross various file formats.
+metadata logics and analyzed common points accross various file formats.
 
 This goes together with a more thorough work currently done by Jacob
 Boerema on metadata handling (some of this work will end up in the GIMP
@@ -330,14 +341,14 @@ GIMP 3).
 
 ## Updated file plug-ins
 
-Only 3 plug-ins so far have benefited from the new generic dialog
-generation API: the PNG, JPEG and TIFF plug-ins. In the most extreme
-case, we shaved 600 lines of code off the JPEG plug-in code!
+Only 4 plug-ins so far have benefited from the new generic dialog
+generation API: the PNG, JPEG, TIFF and FLI plug-ins. In the most
+extreme case, we shaved 600 lines of code off the JPEG plug-in code!
 
-**Note**: we just realized (after release) there may actually be crashes
-now on these 3 plug-ins 😱, which escaped us because they only happen on
-Windows! Pretty bad, but then you discover the joy of running unstable
-versions.
+**Note**: we just discovered (after release) crashes on these 4 plug-ins
+😱, which escaped us because they only happen on Windows! Pretty bad,
+but then you discover the joy of running unstable versions.
+We will fix these as soon as possible.
 
 <figure>
 <img src="{attach}gimp-2.99.4-png-export.png" alt="GIMP 2.99.4: dialog generation on PNG plug-in"/>
@@ -346,6 +357,28 @@ versions.
 </figcaption>
 </figure>
 
+## Multi-threading preferences now available from plug-ins
+
+The Preferences display a "*Number of threads to use*" settings,
+allowing people to customize the thread usage (defaulting to system
+threads detection). This was only used by core processing until now. We
+now make this settings available to plug-ins through
+`gimp_get_num_processors()` API function, hence allowing plug-ins to
+follow user preferences.
+
+The HEIF/AVIF plug-in now uses this function (it was already
+multi-threaded, yet was using system threads discovery with no way to
+override the settings until now). The JPEG2000 loading code, which was
+single-threaded until now, has been ported to use this new function,
+hence decoding images much faster.
+
+## Improved plug-in debugging
+
+The plug-in debugging help infrastructure has been refactored and
+improved by the contributor Lloyd Konneker with features such as the
+ability to differentiate `WARNING` from `CRITICAL` bugs for more
+targetted debugging.
+
 ## Dev docs on porting plug-ins to 3.0
 
 Some embryo of [plug-in porting 
documentation](https://gitlab.gnome.org/GNOME/gimp/-/blob/master/devel-docs/GIMP3-plug-in-porting-guide/)
@@ -357,33 +390,57 @@ ground work can be started already!
 
 # GEGL and babl
 
-FIXME
+In the context of this release, babl 0.1.84 has been released, as well
+as GEGL 0.4.28. These releases mostly contain small fixups.
+
+Some interesting work still got in GEGL, like the new
+"gegl:paint-select" operation by Thomas Manni, which he uses in the new
+experimental tool.
+
+We can also note the new operations "gegl:convert-space",
+"gegl:cast-space" and "gegl:icc-load", as well as some structural
+changes in `GeglOperation` class with a new `is_available()` class
+method allowing to check for operation availability at runtime (this can
+be useful in specific cases, in particular operations relying on runtime
+dependencies).
+
+Øyvind Kolås spent lately much more time on polishing his
+[ctx](https://pippin.gimp.org/ctx/) project (a new 2D vector graphics
+platform/protocol/library/terminal we [talked
+about](https://www.gimp.org/news/2020/01/04/gimp-and-gegl-in-2019/#whats-new-in-gegl-and-babl)
+a year ago.
 
 # Download and bug reporting
 
 We remind this is a development version and therefore issues are bound
 to happen. It is not advised to use these builds for production.
 Nevertheless we are welcoming reports on issues. We fixed 21 reported
-bugs (and many more unreported ones) since [GIMP 2.99.2
+reports (and many more unreported ones) since [GIMP 2.99.2
 release](https://www.gimp.org/news/2020/11/06/gimp-2-99-2-released/) and
 we expect many are still unfixed. Worse we may have created new ones as
 this is very moving code!
 
+Between the GIMP 2.99.2 and 2.99.4, 283 changes were committed to GIMP
+in a bit less than 2 months. This was quite a busy end of year!
+
 * [Development download page](https://www.gimp.org/downloads/devel/)
 * [Bug tracker to report any issue](https://gitlab.gnome.org/GNOME/gimp/)
 
 Note: we still haven't got a build for GIMP 2.99.4 on macOS, yet you may
-have noticed our other news the very same day about finally a [release
-for the GIMP 2.10.22 stable release on
-macOS](https://testing.gimp.org/2020/12/25//gimp-2-10-22-released-macos/)
-(double Christmas!). Therefore things are progressing on this side, and
-an unstable build might happen soon too!
+have noticed our other news from the very same day about finally a
+[release for the GIMP 2.10.22 stable release on
+macOS](https://www.gimp.org/2020/12/25/gimp-2-10-22-released-macos/)
+(double Christmas 🎁!). Therefore things are progressing on this side,
+and an unstable build might happen soon too!
 
 # What's next
 
 A lot more work is still in-progress, so as always, we welcome with very
-opened arms and warm heart any contribution to code, bug investigation,
-themes, icons, documentation, translation, website, builds…
+open arms and warm heart any contribution to code, bug investigation,
+themes, icons, documentation, translation, website, builds… GIMP is a
+community-developed software. We all are GIMP, hence the many very
+helpful elves all over the world helping Santa Claus this year for this
+Christmas present.
 
 We remind our code repository and bug tracker are at: 
[https://gitlab.gnome.org/GNOME/gimp/](https://gitlab.gnome.org/GNOME/gimp/)
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]