I assume that we won't need most of these explicitly in bindings, but
_if_ it's needed, then it's best to make sure that people don't struggle
because they don't have proper API without annotations.
I feel that such section would matter particularly to show some major
issues which we want to finish before a stable release.
This is not necessarily an exhaustive list of blockers, just some major
items.
... since GEGLification of the twain plug-in (2.10.14 and later
versions)
In the data-transfer functions, allocate a temporary buffer for the
converted data on each call using the current chunk size, instead
of reusing the buffer allocated on the first chunk. This allows
for different chunks sizes across calls.
... by grouping the geometry options, which can be controlled
through the on-canvas UI, in an expandable frame, which is
collapsed by default. The shape option is not part of the group,
and is moved to the top.
In _gimp_prop_gui_new_generic(), when a pair of consecutive
properties have "range-start" and "range-end" roles, respectively,
and "luminance" units, use a range prop-widget for both properties,
as per the previous commits.
The range is sorted by default, unless the first property has a
"range-sorted" key of "false".
In GimpHandleBar, add gimp_handle_bar_{set,unset,get}_limits(), to
allow settings the handle-bar limits explicitly, rather than
inheriting the adjustment limits.
... which creates a widget controlling a pair of lower/upper range-
limit properties, comprised of a handle-bar and two spin-buttons.
If the "sorted" parameter is TRUE, the "lower" property is bounded
above by the "upper" property, and vice versa.
... which takes a pair of GtkAdjustments, and binds the value of
the first to the lower-limit of the second, and the value of the
second to the upper-limit of the first.
In tool-group GimpToolButton tooltips, in addition to showing the
description of the currently-active tool, list the other tools in
the group as well, to improve discoverability.
Add a new GimpAccelLabel widget, which shows an accelerator label
for a given GimpAction. Unlike GtkAccelLabel, GimpAccelLabel
doesn't show a user-provided label in addition to that.
Note that the size request of GtkAccelLabel doesn't include the
accelerator part, which is desirable in some contexts.
GimpAccelLabel doesn't suffer from that.
Flatpak repositories can store successive builds (up to 20 in the
Flathub repository in particular), even though by default it installs
only the last build.
I added in `debugging-tips.txt` the commands to search for and
explicitly install an older build of our official GIMP build. This can
be useful to compare some behaviorial changes as reported by users,
without having to re-compile old commits just for a quick test.