GitLab

In GimpBrushTool, remember the settings used for the last cached
brush boundary, and avoid creating a new copy if the settings
didn't change.  This should lower the overhead of
gimp_brush_tool_flush_paint() when not using dynamics.

Also add a note about installing possibly from the release tarball or
from the package manager of a distribution, since apparently some assume
it has to be installed from repository, making their own life harder
that it has to!
Finally split the libmypaint and mypaint-brushes into their own numbers
to make things even clearer.

Which returns the entire GimpContainer of paint options.

Alpha is calculated separately, ne need to run it through babl.
Also some formatting cleanup.

Using CIE Lab yields gradients that more closely resemble the perceptual
gradients but without the gamma based blending problems of linear-RGB / CIE
XYZ.

Commit f5cb1fed, which performed
brush outline generation in GimpPaintTool in synchrony with the
paint thread, wasn't enough, since GimpSourceTool could still call
gimp_brush_tool_create_outline() directly during its
GimpDrawTool::draw() method, leading to the same race condition
when executed concurrently with the paint thread.

Partially revert the above commit, so that outline generation is
handled as before, as far as GimpPaintTool is concenered.  Instead,
add GimpPaintTool::{start,end,flush}_paint() virtual functions; the
first two are called when starting/ending painting using the paint
thread, while the third is called during the display-update
timeout, while the main thread and the paint thread are
synchronized.  This allows subclasses to perform non-thread-safe
actions while the threads are synchronized.

Override these functions in GimpBrushTool, and cache the brush
boundary in the flush() function.  Use the cached boundary in
gimp_brush_tool_create_outline() while painting, to avoid the above
race condition, both when this function is called through
GimpPaintTool, and through GimpSourceTool.

Commit b279c2d2 was breaking a specific use case, which I oversaw:
when space bar activates the move tool, you may want to release the
space bar while mouse button is pressed, and expect to still be able to
move the layer/selection/guide, but releasing space was stopping the
move immediately. The move tool must only be deactivated when both space
and button 1 are released, and the move itself must continue as long as
button 1 is pressed (when started while space was pressed).

As a nice side effect of this commit, panning and canvas rotation are
also improved since now they can be continued while releasing space
(respectively shift-space) if mouse button 1 was pressed, and up until
the mouse button is released. Pressing space again, then releasing the
mouse, back and forth, also work as expected (i.e. move tool stay
activated though the move stops; and panning or rotation continue).

Of course now we don't get anymore panning/rotation stuck while neither
space nor mouse buttons are pressed (which was the original bug). At
least one of these need to stay pressed for panning/rotation/move to
stay activated. And initial activation is obviously always through
(shift-)space only.

It makes more sense than "l" as a default, and "g" was currently unused.
So not much left to ponder.

This one string was still using the old name, which appeared in menus or
in the shortcut list.

This includes migrating properly any custom shortcut (menurc), as well
as a few strings in tool-presets/, and finally "gimp-blend-tool" in
contextrc and devicerc.
File toolrc also has some occurrences, but we are already skipping it
anyway, same as whatever is under tool-options/.
Hopefully I missed nothing.

Rename the tool and its options, and the gradient sub-struct of paint
options.

Rename gimpdrawable-blend.[ch] to gimpdrawable-gradient.[ch]

Rename GimpOperationBlend to GimpOperationGradient.

Rename the tool cursor: blend -> gradient in filename and enum value.

Somehow, gimppalette-import.c was not rebuilt on my system,
leaving one gimp_gradient_get_color_at() unchanged.

Step 1: rename the icon to GIMP_ICON_TOOL_GRADIENT (gimp-tool-gradient)

First WIP commit, adds:

- enum GimpGradientBlendColorSpace { RGB_PERCEPTUAL, RGB_LINEAR }
- linear blending mode for gradient segments
- tool options GUI for the blend and paint tools which use gradients

Don't flush the source pickable in gimp_source_core_motion(), as
this introduces a race condition between the paint thread and the
display-update timeout, when the source pickable is the image
containing the target drawable.

Flushing the source pickable shouldn't be currently necessary, and
either way, should happen during initialization.

Most expected behavior in normal transform is to see the preview,
whereas you usually don't want to see it in corrective mode. In 2.8
actually, it seems like it was not even possible to see the image
preview in corrective mode.

So let's set "show-preview" to these defaults when "direction" property
is updated.  It is still possible to change it manually for any specific
use cases (i.e. you can hide the preview in normal transform, and
oppositely you can show it in corrective transform), but at least now
defaults are sane.

... or during rotation.
If checked before rotation, it works as expected, i.e. one sees only the
original or the rotated image.
While rotation is in progress: if unchecked, one sees neither the
original nor the image preview; if checked, one sees both original and
rotated preview.
Let's make the behavior consistent and only show exactly one version at
all time.

Use memcpy() because we really dont' want to copy the terminating nul,
but we don't want a warning either.