GNOME.org
 

[gimp-web] More GIMP 2.99.4 updates.

commit b51e5c6d01e4fac462e0dd44c89fb3f492b121d2
Author: Jehan <jehan girinstud io>
Date:   Fri Dec 25 23:03:47 2020 +0100

    More GIMP 2.99.4 updates.

 .../2020/2020-12_GIMP-2.99.4_Released/index.md     | 124 +++++++++++----------
 1 file changed, 66 insertions(+), 58 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 c1e0cffd..9f7a17cc 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
@@ -65,7 +65,7 @@ discovery:
 <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, when grabbing, do small updates or text-edit</em>
+<em>GIMP 2.99.4: from left to right, new cursors on the slider to grab, when grabbing, do small updates or 
text-edit</em>
 </figcaption>
 </figure>
 
@@ -75,10 +75,11 @@ 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
-selection and in the same time create or remove masks by mistake.
+layer and mask thumbnails. For instance one could end up changing the
+selected layers while in the same time create or remove layer masks by
+mistake.
 
-Since the multiple selection feature is just too important and these
+Since the multiple layers feature is just too important and these
 generic interactions so well established across software (hence their
 removal or replacement not even a question), here are the design choices
 taken:
@@ -87,7 +88,7 @@ taken:
   only on `Shift`, `Ctrl` or `Shift-Ctrl` modifiers, but it could
   include these if any additional modifier (e.g. `Alt`) comes to play.
 * We moved any existing feature which didn't follow such rule to a
-  `Alt+` combination, as said additional modifier.
+  `Alt+` combination.
 * If all modifier combinations are taken, we removed click-features
   based mostly on seniority.
 * Actions are now based on exact modifier combinations to avoid feature
@@ -114,8 +115,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 being held, hence removing a distraction when this was obvioulsy
-  not what we were looking for.
+  is being held, hence removing a distraction when this was obviously
+  not what the click was for.
 
 ## Input Devices dialog
 
@@ -130,31 +131,30 @@ dialog. This is a work we started earlier and continued for GIMP 2.99.4.
   the `XTEST` device, some kind of test device generated by the X11
   server (Linux).
 * We used to show all possible axes for all devices, including some axes
-  like "Rotation" or "Slider" which are actually only available very
-  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 what a specific device really has because drivers are sometimes
-  over-listing, yet it is still much closer to reality).
+  like "Rotation" or "Slider" which are present very rarely (only on
+  specific drawing styluses in the market, even uncommon among
+  professionals). The dialog will now only list the axes returned by the
+  backend (note that even this list may still show more 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`
   because these devices are usually meant for absolute pointer
-  positionning.
+  positionning whereas it will be `Rel. X` on mice.
 * Curve editing for the tablet pressure response was one of the most
   interesting configuration option in this dialog, even more now that we
   don't need to enable or disable specific devices. This is why when a
   device has a "Pressure" axis, it will be selected by default, hence
-  allowing you to directly work on the curve, without unecessarily
-  clicks.
+  allowing you to directly work on the curve, without unecessary clicks.
 
 **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
-these features? Which OS? What was the goal?
+input from anyone who had actual needs for them. How were you using any
+of these features? Which OS? What was the goal?
 
-* There used to be a "Keys" list for every device in the dialog. We
+* There used to be a "**Keys**" list for every device in the dialog. We
   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
@@ -162,23 +162,23 @@ these features? Which OS? What was the goal?
   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
+  us so that we can think of a way to restore the feature with an
   understandable interface.
-* The "Axes" list has the ability to set the "axis use" for a given
+* 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.
   Has anyone a usage for this axis use settings?
-* Each device has 3 "modes": Disabled, Screen and Window. "Disabled"
+* Each device has 3 "modes": Disabled, Screen and **Window**. "Disabled"
   simply means that the device will share the main virtual device
   pointer while "Screen" will make it look independant. The "Window"
   mode on the other hand is a concept only meaningful for "floating"
-  devices (a concept maybe not even valid on all platforms?) and even
+  devices (a concept maybe not even valid on all platforms) and even
   then it looks broken, as far as our tests went. Is there anyone in the
   world who actually uses the "Window" mode and sees a difference with
-  "Screen"?
+  "Screen" in recent GIMP versions?
 
 If anyone gets a usage of these features, we would definitely welcome
-inputs because we are as puzzled as many on actual usage for these. On
+feedback because we are as puzzled as many on actual usage for these. On
 one hand, if we don't actually find any usage, we are tempted to remove
 the settings. Because it is only a waste of time and efforts to show
 non-working configuration, and it is confusing for everyone. On the
@@ -188,17 +188,19 @@ us how these are used (to contact us, you may for instance open a
 [report](https://gitlab.gnome.org/GNOME/gimp/-/issues) to explain your
 usage as a response to this news)!
 
-Note that if we finally understand how a feature is useful, we might
-actually even be able to improve the settings interface to make it more
+Note that if we finally understand how a feature is to be used, we might
+even be able to improve the settings interface to make it more
 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 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.
+As explained in the [2.99.2
+release](https://www.gimp.org/news/2020/11/06/gimp-2-99-2-released/#improved-input-devices-support),
+GIMP 3 has a much better input 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:
@@ -233,8 +235,8 @@ quickly detect fonts useful for your language of choice in a long list.
 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* have many stylistic variants and are therefore also
+choices, and secondly because the circle shape in 'ㅎ' (hieut) but 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
@@ -296,7 +298,7 @@ interaction interface as a better way to retarget the tool usage.
 Moreover more experiments are still in progress or planned by Thomas, in
 particular to give new ways to refine edges of existing selection (since
 the Paint Select tool is doing binary selections which are less
-appropriate for selection edges).
+appropriate for edge selection).
 This is all to be considered as open development and experiments in Free
 Software. We shall see how things evolve!
 
@@ -323,12 +325,13 @@ 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.
+and Scheme) up to the GIMP 2.10 series. Unlike this past ability, 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 and will provide much better dialogs and advanced logics.
 
-## New generic metadata support API for exporting
+## New generic metadata support API
 
 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
@@ -359,10 +362,10 @@ We will fix these as soon as possible.
 
 ## Multi-threading preferences now available from plug-ins
 
-The Preferences display a "*Number of threads to use*" settings,
+The Preferences dialog proposes 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
+now make this settings available to plug-ins too through
 `gimp_get_num_processors()` API function, hence allowing plug-ins to
 follow user preferences.
 
@@ -376,7 +379,7 @@ hence decoding images much faster.
 
 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
+ability to differentiate `WARNING` from `CRITICAL` bugs for better
 targetted debugging.
 
 ## Dev docs on porting plug-ins to 3.0
@@ -393,7 +396,7 @@ ground work can be started already!
 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
+Some interesting operations still got in GEGL, like the new
 "gegl:paint-select" operation by Thomas Manni, which he uses in the new
 experimental tool.
 
@@ -404,7 +407,7 @@ 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
+Øyvind Kolås spent lately much 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)
@@ -414,14 +417,18 @@ a year ago.
 
 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
-reports (and many more unreported ones) since [GIMP 2.99.2
+Nevertheless we are encouraging early tests and welcome reports as well
+as patches on issues. We fixed 21 reported issues (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!
+Between the GIMP 2.99.2 and 2.99.4, 283 changes were committed to this
+particular development branch of GIMP in a bit less than 2 months. This
+was quite a busy end of year!
+
+A Windows installer and a Flatpak build are already available:
 
 * [Development download page](https://www.gimp.org/downloads/devel/)
 * [Bug tracker to report any issue](https://gitlab.gnome.org/GNOME/gimp/)
@@ -429,20 +436,21 @@ in a bit less than 2 months. This was quite a busy end of year!
 Note: we still haven't got a build for GIMP 2.99.4 on macOS, yet you may
 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/)
+macOS](https://www.gimp.org/news/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!
+and an unstable macOS package might happen soon too!
 
 # What's next
 
 A lot more work is still in-progress, so as always, we welcome with very
-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.
+open arms and warm heart any
+[contribution](https://gitlab.gnome.org/GNOME/gimp/) to code, bug
+investigation, themes, icons, documentation, translation, website,
+builds…
 
-We remind our code repository and bug tracker are at: 
[https://gitlab.gnome.org/GNOME/gimp/](https://gitlab.gnome.org/GNOME/gimp/)
+GIMP is a community-developed software. We all are GIMP, hence all
+contributors are the many very helpful elves all over the world helping
+for this holiday present.
 
 Also we are aware that GTK 4.0 is out, we have no plans switching over
 to it before GIMP 3.0 is released. No need to ask for this!
@@ -452,7 +460,7 @@ developers](https://www.gimp.org/donating/) who make this all possible
 at all. This is also a way to give back and accelerate the development
 of GIMP if you appreciate the project.
 
-Have a very nice Christmas 🥳🎄 and end of 2020 everyone. This year was
+Have a very nice holiday season 🥳🎄 and end of 2020 everyone. This year was
 a bit particular, but maybe some things were good in it for you, and
 hopefully GIMP was one of these things. We sure wish 2021 to go for the
 better for everyone!
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]