It never belonged inside "tools". Also rename its "pdb" subdirectory
to "groups". This had to happen before 2.10 so cherry-picking between
branches doesn't become a nightmare in the future.

... failed.
See bug 791514. It seems that the file opening fails for webp exporting,
but the error string is not informative enough.
As a general rule, we should have as informative errors as possible.

And add the relevant option for when such capability is absent. Right
now it is absent only from the new Freedesktop API.

I am told by the GNOME/Flatpak people that this is what we will
ultimately need to implement. Basically this portal is supposed to work
everywhere, in sandboxes (Flatpak, hopefully Snap too?), but also out
of sandboxes, i.e. in GNOME and KDE, whether Wayland or X11. So that
should be the unique API we will have to implement in the end, and every
desktop environment/sandbox will need to implement this API (which is
good!).
Apparently it is not part of default GNOME yet, but has to be installed
separately (on Fedora, package is xdg-desktop-portal-gtk for GNOME and
xdg-desktop-portal-kde for KDE).

Now there are currently many shortcomings, and in particular, the
screenshot API has apparently no advanced features (at all!). No window
snap, no rectangular selection, no delaying, no choice on including
cursor or decoration, nothing! Apparently this is normal that the API
presents no feature, because "the API itself is not meant to specify the
details how the screenshot is obtained. Instead the portal will present
the user a dialog to take a screenshot, and that screenshot will be
given back to the sandboxed app".
This is acceptable behavior, except that currently, the dialog has none
of the basic features so this is a very bad regression. This is why I
test the freedesktop API last, which basically means it will likely
never be actually used. That's on purpose. At least, the code is in and
will be easy to improve later. Of course, when the Freedesktop portal
for screenshot will finally be featureful, it is meant to be tested
first.

See: https://github.com/flatpak/xdg-desktop-portal/blob/master/data/org.freedesktop.portal.Screenshot.xml

I assumed we would switch to RC releases now (cf. IRC discussions). This
can be changed later if we finally decide to do another dev release
instead.

Oups!

It seems we forgot to move librsvg from optional to mandatory
dependency. Also add RawTherapee as an optional runtime dependency.
Finally reorder the lists alphabetically.

This variable is used for the MimeType key in the desktop file, which
allows to know if a software can open a file with the Exec key command.
Whether GIMP can also export such format is not to be taken into
consideration.

Poppler and poppler-data are now hard dependencies.
PDF is a common-enough format nowadays that import support is likely
considered as a granted feature by everyone. Moreover the current
fallback to the PostScript plug-in for PDF support just gives a degraded
experience with less features (and probably a lot of bugs since
basically nobody uses this code).
Poppler-data is also considered mandatory because non-western language
support should never be considered an "option". People using non-western
languages are not second class citizens and therefore if we say that PDF
import is now a hard feature, it should also include PDF using CJK or
Cyrillic languages.

A little late for this small typo, but let's still fix it.

Even though we don't have an official build yet (flatpak only does
stable builds), let's keep up with the releases. :-)

Massimo Valentini authored Dec 08, 2017 and Michael Natterer committed Dec 12, 2017

s/LAYER-MODE-NORMAL/LAYER-MODE-NORMAL-LEGACY/ almost makes it
look like before.

These were modified after a `make distcheck`.
Push the changes as per devel-docs/release-howto.txt.

Unless some were not listed as authors of their respective commits, that
should be the full list.

- OpenCL disabled by default.
- Manual localization choice in preferences.
- Abbreviated layer mode names.
- Free Select tool commit with double click.
- Color tags inherited from parents.
- "Wheel" dynamics also works for "Rotation" feature.
Preparing for 2.9.8 release. Hopefully I did not forget any other
worthwhile change!

It turns out we already have the support since it uses the same axis as
the "wheel", used by other devices (for instance the Airbrush pen of
Wacom has a wheel reporting on this same axis).
We can't do any fancy support for this right now, but at least we can
clarify a bit the dynamics naming so that people understands it can be
used for both wheel and rotation input.
Fix the various "Wheel" dynamics strings into "Wheel/Rotation".

Since SRTM-1 and SRTM-3 data have a fixed image size, it is actually
very easy to auto-detect these by checking the file size. There is no
need to ask the user to select between the 2 variants (even though these
values are made quite obvious by official download links).
I still left the dropdown appear optionally if the detection fails for
some reason (we never know, at least that makes a fallback, for instance
to be able to load partial data!). Yet now by default, HGT file settings
should be fully auto-detected.

... and minor space and indentation fix.

g_set_error() so that when samplespacing is not a valid argument for
file-hgt-load, the error is properly propagated.
Also add a g_warning() to get the error in the terminal as well.

Likely a copy-paste typo. Nothing serious, but since I saw it, let's fix
it.

This allows for it to show as a separate item in the open dialog, with
proper naming. Also add proper arguments so that the handler works as a
PDB function in non-interactive mode, unlike file-raw-load which works
only interactively.

Also move the Color Picker section from tools to core. This is not about
the Color Picker tool (which only picks inside the canvas and doesn't
care about Wayland or not) but about the generic widget which can also
pick colors out of canvas (and even out of GIMP windows).