GitLab

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).

... capabilities.
This is untested, just reading the docs of "screencapture" tool we use
for macOS support. Hopefully it's all fine! :-)

The plug-in dialog GUI was always visible in my full-screen screenshots
on KDE, when no delay. It seems the culprit is their fading out effect
which takes longer than the screenshot to happen, therefore the dialog
was showing up with transparency.

This indicates if a delay can be inserted in-between the window pick and
the actual shot. This is indeed not always possible, for instance using
KWin API. Obviously this feature is only meaningful if
SCREENSHOT_CAN_PICK_WINDOW feature is enabled as well. For instance X11
screenshot has the feature, but GNOME won't need it since there is no
window selection (it simply snaps whatever is the active window).

Small fix on previous commit.

... and a delay before the screenshot.
Until now, there was only delay before selection, which I changed in
commits d9cd4b61 and 614bcf6d. Actually a delay before selection may
also be useful, for instance when you use a tablet without keyboard (no
alt-tab possible) and the window/area you wish to capture is behind GIMP
window. Then you'd want to interact with the desktop with the pointer
before the cursor changes for selection interaction.
I add some logics so that the selection delay doesn't show when it is
unecessary (for instance for full-screen screenshot, or when the window
screenshot is based on the active window, not click selection, like with
GNOME shell API).

"Digital Elevation Model" (DEM) is a technical term which therefore
cannot be translated just by its meaning.

- Display title "Digital Elevation Model data" instead of just "Image".
- Don't show the type combo anymore, since HGT is always 16-bit signed
  integer in big endian.
- Don't show the width and height either, but instead show a dropdown
  list to choose between either SRTM-1 or SRTM-3 data. There seems to be
  only these 2 types of data, and this will determine the width and
  height. This choice (SRTM-1 vs 3) will mostly likely be better known
  by people than knowing what image dimension they have to set,
  especially since official links for such files seem to all include the
  information.

- Add some parentheses to sizeof (*pointer). Maybe it's just me, but it
  is just a bit clearer to me.
- Free in_raw when out_raw allocation failed.
- Use strrchr() instead of strchr() to get the extension (I had a case
  when testing where the file was inside a folder named similarly with a
  ".hgt" and it would break the comparison test).
- Do a case-insensitive comparison. Even though the original files from
  NASA use lowercase, just to be sure.

add support to load single channel 16 bit, signed/unsigned,
little/big endian 2d raster data as a 16 bit RGB gamma GIMP image

I just cross-compiled for Windows after a long time. The header file is
all lowercase on a cross-compilation MinGW-w64 environment. I'm not sure
what is the case on Windows, but since this platform is case-insensitive
for file names, I believe this won't break anything on native builds.

The screenshot-win32.c file was absolutely not following our coding
style. A lot of things are still wrong (like camelCase functions), but
at least I fixed a bunch of indentations, space between function and
arguments, alignments, curly brackets at start of lines, etc.

Use CAIRO_FILTER_FAST when painting the xfer surface to the
screen.  This notably improves performance when the canvas is
rotated, at the cost of lower filtering quality.

Based on a patch by Massimo.

Move the entire image-space/screen-space transformation logic from
gimp_display_shell_render() to gimp_display_shell_draw_image(), so
that the former works entirely in image space, and do the chunking
and clipping in screen-space, making sure that image-space chunks
are never larger than
GIMP_DISPLAY_RENDER_BUF_WIDTH x GIMP_DISPLAY_RENDER_BUF_HEIGHT,
even when the window's scale factor is greater than 1.

Add a GIMP_BRICK_WALL environment variable, which, when set, shows
the screen-space chunk bounds.

Delay should indeed happen before root and window screenshots, but must
happen in-between region selection and region screenshot.

One can notice that the logics is different for Windows screenshot in
X11. The reason is that X11 window screenshot has an additional window
selection step (and therefore delay must happen in between selection and
actual screenshot). Window screenshot in Wayland doesn't have this step
and simply screenshots whatever is the currently active Window.

Fix first the delay in X11.
Actually both for region and window screenshots, it makes no sense to
delay *before* region or window selection. Usually when one uses a
delay, the point is to prepare in-between selection and shot. For
instance, I often used a delay to snap the contents of a menu because
PrintScreen key would not work when a menu is opened. So I would set a
delay, select my window/region, then quickly open the menu before the
delay is counting down. This would not be possible with the way delay
occurred (before selection), which just has no use that I can see of.

Though forward declarations of the implementations are ok, it is cleaner
to have proper header files for each variant (default, kwin, quartz
right now). Of course these new header files are not installed and must
be kept private for build only.

Add support for KWin API, for KDE on Wayland.
Unfortunately though, KWin's "pick" API seems to have failures, so I
fallback to the default color picking when this happens. This will still
not work on Wayland, but at least won't cause regression for color
picking on KDE/X11.
See also KDE bug: https://bugs.kde.org/show_bug.cgi?id=387720

The risk of search and replace. Bad me!

Though the bug was mostly fixed, it seems to still happen on Windows XP,
where apparently no content type had been registered for SVG.
GTK+ developers don't seem too keen to patch GTK+ 2.24 for a platform
which they don't support anymore.

Also if not mistaken, GIMP does not officially support Windows XP
anymore either. A patch though has already been provided by Edward E.
and it really doesn't look like it could break anything since it just
adds a last "else if" when everything else failed (and inside a #ifdef
affecting only WIN32 builds).
So let's just add it in our builds at least. We still don't have support
for it, but I see no reason to just refuse a minor patch which won't
break anything else.

Only thing I could not properly figure out yet is how to select an area.
The "screenshotArea" method is there in KDE API, but it needs
coordinates and I can't find the API to grab coordinates in Wayland (as
in GNOME shell API).

... when inserting/reordering items

Otherwise, newly inserted/reordered group layers are always
collapsed.

... so that duplicated group layers maintain the expanded state of
the original.