[gimp-web] contents: update GIMP 2.99.2 news.



commit 2917e98f73598c13f03db29c32a46315931984fa
Author: Jehan <jehan girinstud io>
Date:   Sat Oct 24 16:41:49 2020 +0200

    contents: update GIMP 2.99.2 news.
    
    Prepare for tomorrow!

 .../2020/2020-06_GIMP-2.99.2_Released/index.md     | 395 ++++++++++++++++++---
 1 file changed, 352 insertions(+), 43 deletions(-)
---
diff --git a/content/news/2020/2020-06_GIMP-2.99.2_Released/index.md 
b/content/news/2020/2020-06_GIMP-2.99.2_Released/index.md
index a9858986..fe07c056 100644
--- a/content/news/2020/2020-06_GIMP-2.99.2_Released/index.md
+++ b/content/news/2020/2020-06_GIMP-2.99.2_Released/index.md
@@ -1,5 +1,5 @@
 Title: GIMP 2.99.2 Released
-Date: 2020-10-17
+Date: 2020-10-25
 Category: News
 Authors: Wilber
 Slug: gimp-2-99-2-released
@@ -21,56 +21,97 @@ Release highlights:
 ## GTK3 based UI
 
 The first difference will be visual as you will notice that GIMP got a
-bit more of a modern look now and it can also use some new widgets
-(instead of redevelopping them on GTK2). But the esthetical differences
-are far from being the main appeal of GTK3.
+bit more of a modern look and it can also use some new widgets (instead
+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?
 
 ### High pixel density displays
 
-One of the main issues of GTK2 for nowaday material 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 for nowaday display material 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.
 
-GTK3 brings proper support to GIMP whose graphical interface will follow
-your system-set scale settings.
+GTK3 brings proper support to GIMP whose whole graphical interface will
+follow your system-set scale settings.
 
 ### Improved input devices support
 
-By "input device", we are mostly talking about drawing tablet or
+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 fixed on GTK2 by GIMP developers within the 2.8
-branch release period).
+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
-to draw.
+to draw, with pressure, tilt and everything.
 
 We are also trying to improve general support by making our input device
 advanced configuration easier to use.
 
+It is to be noted that some touch support work had been experimented a
+while ago but has not been finished because we realized this was not a
+priority compared to some other features (we are talking about specific
+touch features, like zooming, panning, rotating or other gestures made
+with fingers; *touch* as an input device already works and was also
+already working with GIMP 2 versions). Touch gestures are very nice and
+awesome but also sometimes becomes a burden. Actually many professional
+graphists even disable touch-sensitivity to prevent unwanted inputs
+while working with a stylus (high-end tablets often come with a physical
+switch for this nowadays, and this can also be disabled by tablet
+settings). With this in mind, we have decided to not make it a priority
+and it is therefore not sure if 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*: some 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.
+
 ### Theming
 
-With GTK3, we also inherit its CSS-based theme format. This
-unfortunately means that all custom-made themes from past versions will
-be incompatible in GIMP 3 and over. On the other side, this new theme
+With GTK3, we also inherit its CSS-based theme format. Unfortunately
+this means that all custom-made themes from past versions will be
+incompatible in GIMP 3 and over. On the bright side, this new theme
 format using a very well known theming standard should make it much
 easier to tweak GIMP interface to your needs and preferences.
 
 Moreover symbolic icon theme are much better supported. They will follow
 the theme-set foreground and background colors. For anyone who changed
-your theme in GIMP 2.10 from dark to a light theme, you probably
+one's theme in GIMP 2.10 from dark to a light theme, you probably
 remember you also had to switch the symbolic icon themes manually. This
 won't be necessary anymore.
 
-Finally a same theme may propose both symbolic and color icons. Our Icon
-Theme preferences provides a "*Use symbolic icons if available*"
-checkbox allowing you to indicate your prefered style.
+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
+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.
+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
+GIMP needs to default to a neutral color theme with symbolic icons (of
+course, people are free to install pretty-colored themes and icons,
+and I'm sure that the community will quickly create awesome ones).
+Unfortunately we currently have no contributions in this regard. This is
+a very good way to contribute to GIMP as a non-developer. **We welcome
+theme designers very warmly!**
 
 ### Wayland support
 
@@ -85,8 +126,8 @@ less serious but still a bit embarassing (broken splash image with high
 density scaling because Wayland doesn't report scaling properly).
 So we probably can't say we have an appropriate Wayland support unless
 these issues get fixed. We welcome very warmly patches on this matter
-(on GIMP or GTK side depending on investigation): [list of
-Wayland-related
+(on GIMP, GTK or other part of the stack depending on what we find out):
+[list of Wayland-related
 
bugs](https://gitlab.gnome.org/GNOME/gimp/-/issues?scope=all&utf8=%E2%9C%93&state=opened&label_name[]=Environment%3AWayland).
 
 With Wayland comes also the need to reimplement a few features through
@@ -99,13 +140,156 @@ 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.
 
-## Refactoring
+## Multi-layer selection
+
+One of the major annoyance of layer management in GIMP until now was the
+inability to select more than one layer. Before even being a pixel
+processing feature, this is an organizational bother for professional
+and advanced users who often use several dozens of layers in their most
+complicated images. Imagine having to move 20 layers into a layer group,
+or reordering them, one by one, tediously…
+
+[Aryeom](https://film.zemarmot.net/en/), the animation film director
+working with the core team, has been asking for this ever since 2015, so
+*ZeMarmot* project finally worked to make this happen. This was another
+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
+
+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.
+
+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
+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
+"Sample merged" without having to hide unwanted layers).
+
+These are only a few examples because this change really spreads through
+the whole codebase, since the concept of "active layer" is prominent
+in every action. You are welcome to read through this [development
+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
+broken (that's why we have development releases, to discover bugs!).
+
+Moreover we may extend the multi-item selection ability 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
+specification and designing to prevent undesired consequences (extremely
+slow operation, ability to cancel long-running process and early
+discovery of mistake editing are the main design issues to solve).
 
 ## Plug-in API
 
 ### Improvements
 
-TODO
+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
+ported to GIMP 3 in between 5 and 30 minutes. We will provide a porting
+documentation when releasing GIMP 3.
+
+#### Object API
+
+Among the noteworthy changes, we moved away from object IDs to real
+objects. In particular in GIMP 3, `GimpImage`, `GimpItem`,
+`GimpDrawable`, `GimpLayer`, `GimpVectors`, `GimpChannel` and `GimpPDB`
+are objects (other classes of objects already exist or may be added
+later).
+
+It brings safer programming by having typed objects whose class can be
+easily verified, hence better error messaging (with IDs, which are
+basically integers, having weird bugs because of improper IDs was not
+uncommon and it was not always easy to track the bug).
+
+Also object-programming implies class inheritance. Typically a
+`GimpLayer` is also a `GimpDrawable`, itself a `GimpItem`. This means
+you can use any methods from parent classes and easily test for class
+ownership.
+
+A non-C consequence is that it enables bindings to adapt the API to
+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
+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
+
+Another change in our API is that paths are now handled as `GFile`,
+which means 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
+operating systems regarding folder separation or file system notations.
+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).
+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).
+
+#### Plug-in declaration
+
+The biggest 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
+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.
+
+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
+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
+with the argument representation.
 
 ### Bindings
 
@@ -120,10 +304,10 @@ 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, an additional layer API is not needed anymore. This
-means in particular that the API is basically the same for all these
-languages, except for language specificity.
+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.
+This means in particular that the API is basically the same for all
+these languages, except for language idiosyncracies.
 
 Therefore if finding an intersection of a drawable with a selection in C
 is:
@@ -141,7 +325,27 @@ let [ intersect, x, y, width, height ] = drawable.mask_intersect();
 Or again in Python 3:
 
 ```python
-intersect, x, y, width, height = drawable.mask_intersect();
+intersect, x, y, width, height = drawable.mask_intersect()
+```
+
+Another nice example is how C-type arrays, with an additional length
+arguments are handled. As expected, the length argument does not exist
+in a binding if the target language has an appropriate structure.
+For instance, while you can copy from multiple drawables from a script
+with:
+
+```C
+/* Where @drawables is a C array of drawables, and @num_drawables
+ * indicates the size of this array.
+ */
+gimp_edit_copy (num_drawables, drawables);
+```
+
+This can be done in Python 3 as (with `num_drawables` removed and C array
+replaced by a Python list):
+
+```python
+Gimp.edit_copy([drawable1, drawable2, drawable3])
 ```
 
 One of the other main advantages is that non only do these binding now
@@ -152,16 +356,23 @@ can have access to the full GTK API as well, or the babl and GEGL API
 operations). This was one of the main limitation of the former Python
 API for instance, which could not manipulate pixels with GEGL.
 
-Of course some people are regretting the facilities provided by the
-specific Python plug-ins, such as automatic dialog creation. These are
-things we plan on working to simply provide to the main API, hence to
-all binginds.
+*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.
+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.
 
 Finally Script-fu is not one of the introspected bindings (though there
-is supposedly a GObject Introspecting scheme binding, but we haven't
-tested it) and still works as its own extension. Some issues regarding
-some of the API changes have been raised and will have to be fixed
-before finale stable release.
+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.
 
 ### Goat exercises
 
@@ -185,9 +396,28 @@ exciting that a bare "Hello World").
 
 ## Extensions
 
+TODO
+
 ## Space invasion
 
-## Multi-layer selection
+"*Space invasion*" is the internal code name for the work originally
+started in
+[2018](https://www.gimp.org/news/2018/08/19/gimp-2-10-6-released/#prepare-for-the-space-invasion)
+whose goal was proper support of color space during core pixel
+processing. In the GIMP 2.10 series, despite core color management
+support, the profiles were sometimes lost during an operation processing
+and only reintroduced on finale results, which may result in wrong
+values in some cases.
+
+Anyone interested to understand further the problematics can read
+[Øyvind Kolås's post](https://www.patreon.com/posts/20264674) and in
+particular the detailed associated [release notes for GEGL
+0.4.6](https://gegl.org/NEWS.html#_gegl_0_4_6_2018_07_23) where he
+explains this really well.
+
+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.
 
 ## Render caching
 
@@ -202,6 +432,85 @@ 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).
 
+## Refactoring
+
+TODO
+
+## Packaging
+### Beta Flatpak available
+
+This release is available in the "beta" branch of our [official Flathub
+package](https://flathub.org/apps/details/org.gimp.GIMP), which is a
+hidden release branch (you won't find this information on the public
+web page). This command will allow you to install GIMP 2.99.2:
+
+```
+flatpak remote-add --user flathub-beta https://flathub.org/beta-repo/flathub-beta.flatpakrepo
+flatpak install --user flathub-beta org.gimp.GIMP
+```
+
+From now on, you will be able to update to new development builds as
+soon as they are available through this channel (if your desktop has
+Flatpak integration, it might even check and propose you the updates
+automatically).
+
+Note that Flatpak only allows one visible branch of a same application
+at once. So if you installed both the stable and development releases
+with Flatpak, your desktop in particular will only show either one or
+the other. To switch the visible branch, run the relevant command among
+the 2 proposed below:
+
+```
+flatpak make-current --user org.gimp.GIMP beta
+flatpak make-current --user org.gimp.GIMP stable
+```
+
+### Windows
+
+As usual, we provide a Windows installer for GIMP, you will find it on the
+[Development Downloads page](https://www.gimp.org/downloads/devel/).
+
+### macOS
+
+Our macOS packager has still not fully returned, so unfortunately there
+is no official macOS package. As always, we remind that GIMP is a Free
+Software developed as a community. It means that any of you can become
+an official package maintainer (or hopefully even several of you for
+redundancy).
+
+If you are interested, we suggest to get in touch with us on our
+[IRC](https://www.gimp.org/irc.html) channel for developers, `#gimp`.
+
 ## What's next
 
-Further refactoring. Further UI cleanup.
+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.
+
+This [development
+report](https://www.patreon.com/posts/what-remains-to-40087754) lists
+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.
+
+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
+cleanups to take care of, be it on plug-ins, core code, user interface,
+application interface… everwhere! This also means that it is the step
+where it's the easiest to miss some of the details. This is why the more
+eyes are looking, the better we can find all the little issues before
+making a finale release.
+
+To conclude, we remind that you can [donate to the project and
+personally fund several GIMP
+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.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]