Move GimpRectangleSelectTool's image undo/redo logic to
GimpSelectionTool, by adding a pair of
gimp_selection_tool_{start,end}_change() functions. These
functions should be called by subclasses before/after changing the
selection, having the functions take care of undoing/redoing the
existing selection as necessary. This allows us to reuse this
logic in other selection tools, specifically, the free-select tool.
(cherry picked from commit 4612105e52)
In gimp_container_tree_view_clear_items(), temporarily unset the
tree-view's model before clearing it, so that name editing is
stopped beforehand. Otherwise, name editing is stopped once the
corresponding item is removed from the store, causing us to rename
the wrong item.
(cherry picked from commit bb8648a2e9)
In gimp_open_dialog_set_image(), use a weak pointer for storing the
current image, to avoid a segfault in file_open_dialog_response()
if the active image at the time of the open action has been closed
before confirming the dialog.
(cherry picked from commit b01113741e)
In the Curves tool, explicitly set the point-coordinate spin-
buttons' width-chars, so that their size remains fixed when their
range changes.
(cherry picked from commit 8fc94184a8)
In the Curves tool, when the image precision is greater than 8-bpc,
use a 0.00-100.00 range for the point-coordinate spin-buttons,
instead of a 0-255 range.
(cherry picked from commit be719f9070)
Allow setting the type of GimpCurve control-points to either SMOOTH
or CORNER. Smooth points produce a smooth curve, while corner
points produce a sharp curve (previously, all points were smooth).
In GimpCureView, display corner points using a diamond shape,
instead of a circle.
In the Curves tool, allow changing the curve's point types.
(cherry picked from commit 33e47c85a2)
Add input/output spin-buttons to the Curves tool, which allow
setting the selected point's coordinates numerically.
(cherry picked from commit 5140d903b8)
In GimpCurve, replace the use of a fixed-length control-point array
with a dynamically-sized array. Adapt GimpCurve's interface, and
the rest of the code.
In addition to simplifying the code, this fixes a bug where the
curve object could be broken by moving the mouse too fast (yep...),
and allows more accurate point placement, both in the GUI editor,
and through canvas interaction in the Curves tool (see issue #814).
(cherry picked from commit b6d829a1b2)
In GimpCurveView, when holding down Ctrl while adding/dragging a
point, snap the y-coordinate to the original curve (at the start of
the drag). This is particularly useful for adding points along the
curve, without changing their y-coordinate.
Likewise, have the coordinate indicator show the snapped
coordinate.
(cherry picked from commit 8357c9ad64)
In GimpCurveView, when dragging an existing curve point, don't
immediately move the point to the cursor position uppon button
press, but rather move it relative to its current position as the
cursor moves. This allows selecting a point without moving it, and
adjusting its position more easily.
Additionally, when the cursor hovers above a point, or when
dargging a point, have the coordinate indicator show the point's
position, rather than the cursor's.
(cherry picked from commit 0b9737a3ed)
Add an "Incremental" option to the Dodge/Burn tool, which,
similarly to the Paintbrush, Pencil, and Eraser tools, applies the
effect incrementally as the pointer moves.
(cherry picked from commit 83184d1626)
... linear itself AND if we export the profile.
Implement similar logics to WebP export as I did to JPEG in my previous
commit.
(cherry picked from commit b9458f8a6e)
... linear itself AND if we export the profile.
In most cases we want to save 8-bit image formats (here JPEG) as
non-linear, even though the work image may have been linear itself (yet
with higher bit depth). The reasons are shadow posterization on low bit
depth, and the fact that JPEG compression was designed for perceptually
uniform RGB and introduces shadow artifacts with linear RGB (see #1070,
message by Elle Stone). The only exception is when the creator was
working explicitly on 8-bit linear (not higher bit depth) AND if we
export the profile (otherwise most loaders around assume sRGB). In such
a case, let's consider the creator knows what one is doing and keep the
exported image linear.
Similar logics is already used in PNG exporter (though a bit of a
variant since PNG supports 16-bit so it is instead: 8-bit linear without
profile is promoted to 16-bit non-linear, and kept 8-bit linear with
profile).
(cherry picked from commit 5f4cf53519)
... produces incorrect result.
Similar to previous fixes to JPEG and PNG exporters. Here WebP always
export 8-bit per channel colors, so let's always keep it non-linear.
Simply when the original data was linear, if we save the profile,
convert it to sRGB before exporting.
(cherry picked from commit 7a4b313b12)
... linear XCF.
When choosing a specific pixel format (other than "Automatic"), we
always export as non-linear. Therefore if we were going to save a linear
profile, make sure we also convert it to sRGB too.
(cherry picked from commit c5fae74ac1)
... produces jpeg in linear color space.
The problem was that we were anyway always exporting to non-linear while
attaching a linear profile. A first approach would have been to export
in linear instead when the work image is linear, as proposed by mitch in
a first version of the patch. Yet as Elle Stone notes, it is not a great
idea to export 8-bit images as linear.
Instead let's continue to always export as non-linear, as we were
already doing. Yet when we also save a profile, and this one was
originally linear, let's convert it to sRGB TRC before exporting.
(cherry picked from commit 8594275bb7)
