GitLab

Make "Tool icon with crosshair" the default cursor-mode, it should
have been like that all along...

If the user enters a value in the shear tool dialog, that value must
be honored. Always set the shear direction to the edited axis and
reset the other axis to 0.

Use a GimpSpinScale widget instead of scale entry cruft, it handles
the model vs. view factor of 100.0 correctly. Also modernize the GUI
without using a table.

It is possible to trigger a heap overflow with insanely large GBR
files with a deprecated file format on 32 bit systems.

The problem is that old versions of GBR allowed an additional pattern
after the brush data. These patterns have always 4 bytes per pixel,
but the initial size check is performed with the bytes per pixel of
the brush, which can be different.

If the brush has 1 byte per pixel and the dimensions are sufficiently
large, this can trigger a heap overflow with attacker-controlled
amount and content of data.
Signed-off-by: Tobias Stoeckmann <tobias@stoeckmann.org>

The C language only promotes data values up to (un)signed int,
which is 32 bit, if no larger data type is used within the
calculation. Having a multiplication of two gint variables,
even if the expected target variable is of type gsize (64 bit),
leads to a possible integer overflow.

This bug can be triggered in gimp_temp_buf_new, which is used
to allocate memory for given supplied dimensions and bytes per
pixel. If triggered, less memory than needed is allocated and
therefore allows out of boundary accesses, either resulting in
possible code execution or information leakage.

While at it, make sure that the supplied format can actually be
resolved to a bytes per pixel value. If not, return NULL.
Signed-off-by: Tobias Stoeckmann <tobias@stoeckmann.org>

...mergedimage.png

fix also the thumbnail creation, that:
must be 8 bit; should not be upscaled; should not have frame
or decoration, that I interpreted as when there are transparent
areas they should not be blended with a background color,
so instead of image_flatten use  image_merge_visible_layers
(also for the merged_image)

Replace gimp_parameter_*() utility functions with equivalent
gimp_properties_*() functions which deal with separate arrays of names
and values, and use g_object_new_with_properties() instead of
g_object_newv().

Enable "save-tool-options" and "save-device-status" by default,
it's the expected behavior these days.

...lists files that do not use deprecated functions

Better regex that matches the right stuff.

- make RED the default channel and reorder RGB before LCH/HSV
- use more of the new getters
- also use more of the previously existing setters

After commit 8029508f, we always
render the image in chunks that are at most
GIMP_DISPLAY_RENDER_BUF_WIDTH x GIMP_DISPLAY_RENDER_BUF_HEIGHT,
even when the window's scale factor is > 1.

... and the mask offset != (0, 0)

Thanks tmanni!

This is WIP in the middle of cleaning up GimpColorSelector subclasses:

Add the possibility to switch between LCH and LSV and between 0..100
and 0..255 RGB in to GimpColorScales. Works almost fine, but needs
different UI to change the options...

Instead, add GIMP_ICON_* defines for new icons.

Also add API docs, pretty basic ones.

This reverts commit 40bc5307.

It's not *exactly* the same. The floating selection can belong to a
channel or layer mask. Also, this belongs into the GUI layer, not the
core.

That makes critical errors:
> GLib-CRITICAL **: g_error_new_literal: assertion 'domain != 0' failed

Anchoring a floating layer is basically equivalent to merge down. This
is already what we do in other merging actions (flatten image and merge
visible layers).

Forbid merging down a floating selection.
Probably we can do something better. But that's a first step.

Refactor GimpDashboard to autogenerate the UI based on a
description of the different variables, fields, and groups.

Allow individual groups to be expanded/collapsed, and individual
fields to be enabled/disabled.  Save the relevant state in the
dashboard's aux-info.

Add fields for the new GeglStats properties, as per GEGL commit
25c39ce6c9bb618f06ac96d118e624be66464d74.  The new fields are not
enabled by default.

Add "reset" action, to clear the history, and reset cumulative
data.

... which can be used to individually enable/disable meter values,
while maintaining the rest of their properties, and their samples.

Also, cleanup.

commit 21bed1e2

moved the lines

+  run_mode = param[0].data.d_int32;
+

without considering the plug-in registers parameterless
procedures

Since they are both mandatory dependencies now, no need to do a nested
check anymore. Also I was getting some weird warnings in the configure
output (maybe also because of missing square brackets?), which are
coincidentally fixed this way as well.

So it seems that [[]] are needed to quote the command part of
AC_CONFIG_COMMANDS(), in particular when square brackets are used inside
the command (which is our case since we used sed with regex classes []).
It is not even in the docs of AC_CONFIG_COMMANDS() but I found this
information in the docs of the deprecated AC_OUTPUT_COMMANDS()!
https://www.gnu.org/software/autoconf/manual/autoconf.html#index-AC_005fOUTPUT_005fCOMMANDS-2135

> Conversely, where one level of quoting was enough for literal strings
> with AC_OUTPUT_COMMANDS, you need two with AC_CONFIG_COMMANDS. The
> following lines are equivalent:
>    AC_OUTPUT_COMMANDS([echo "Square brackets: []"])
>    AC_CONFIG_COMMANDS([default], [[echo "Square brackets: []"]])