When switching between the save/export dialogs, preserve the
dirname part of the path (or rather, use it to set the dialog's
current folder,) not just the basename.
When rendering a gradient with a repeat mode of NONE, don't sample
the gradient at 0.0 and 1.0, for pixels that lie to the left and to
the right of the gradient, respectively. Instead, use the left
color of the leftmost segment directly, and, likewise, the right
color of the rightmost segment. This always gives us the right
color for such pixels, even when there are gradient stops, that may
use different colors, at 0.0 and 1.0,
Remember the gradient segment at which the most-recent sample lies,
and pass it to gimp_gradient_get_color_at() as a seed for segement
lookup on the next sample. This improves the performance
marginally.
When one of the line widget's properties changes, only update the
blend tool filter if the property has an effect on the result. In
particular, don't update the filter when only the selection
changes.
Separate the handling of changes to the FG/BG color from the gradient
dirty signal handling, so that the gradient editor doesn't purge the
history in response. Additionally, correctly respond to such changes
whenever the gradient has segments that depend on the FG/BG colors,
even if the dependency is introduced after the gradient is selected.
Move the tool undo functionality of the blend tool to the editor,
and add support for undoing gradient edit operations. Each undo
step that affects the gradient holds, in addition to the line
endpoint poisitions, a copy of the gradient at the beginning of the
operation, as well as necessary information to allow the selection
to "follow" undo. When undoing the operation, the saved gradient
is copied back to the active gradient.
To avoid all kinds of complex scenarios, when the active gradient
changes, or when the gradient is modified externally (e.g., by the
(old) gradient editor), all undo steps that affect the gradient are
deleted from the history, while those that affect only the endpoint
positions are kept.
Allows setting the midpoint's position, blending function, and
coloring type.
The midpoint can be converted to a stop, and centered, through
editor buttons.
Allows setting the stop's position, and its left and right colors
and color types. A chain button can be used to modify the two
colors (and color types) together.
The stop can be deleted through an editor button.
To be used by the blend tool gradient editor to edit the gradient
endpoint/stop/midpoint properties corresponding to the selected
handle.
The GUI is currently empty; the following commits add its contents.
When a midpoint is double-clicked, convert it into a gradient stop
(i.e., split the corresponding segment at the midpoint,) by
responding to the line's handle-clicked signal.
Add a tentative_gradient member to GimpBlendTool, which, when set,
is displayed instead of the current gradient.
Use this to show a version of the gradient with the currently
selected stop deleted, upon receiving a prepare-to-remove-slider
signal, i.e., when the slider is about to be removed.
Add a boolean "modify active gradient" option to the blend tool.
when checked, the active gradient is modified in-place while edited.
When unchecked, the active gradient is copied to the internal
"custom" gradient upon editing, and the custom gradient becomes
subsequently active.
Show a hint when the option is checked, but the active gradient is
non-writable, and can't be edited directly.
This commit adds the new gimpblendtool-editor.[hc] files, which are
where the gradient-editing related functionality of the blend tool
is going to go.
Add a boolean "instant mode" option to the blend tool, togglable
using shift. When checked, commit the gradient immediately when
the mouse is released.
When not in instant mode, don't commit the gradient when clicking
outside the line, since this will become easy to do accidentally
once we add on-canvas gradient editing.
Add gimp_color_panel_dialong_response() to GimpColorPanel, which
emits a response for the color panel's color dialog, if shown.
Add a "response" signal to GimpColorPanel, which is emitted upon
color dialog response.
In both cases, the response is a GimpColorDialogState, which should
be either GIMP_COLOR_DIALOG_OK or GIMP_COLOR_DIALOG_CANCEL, and not
an actual dialog response id.
Use gimp_gradient_get_{left,right}_flat_color(), instead of
gimp_gradient_get_color_at(), to get the selection endpoints'
colors in the gradient editor, so that the correct colors are used
under any condition (in particular, if there are 0-length
segments.)
When using gimp_gradient_segment_range_compress() to expand a 0-
length segment, redistribute the range's endpoints and midpoints
uniformly, rather than using the regular code path, which would
result in NaN values.
Make sure that the left and right endpoints of the range are
*exactly* equal to the new left and right values. Previously,
they could be slightly off due to numerical errors.
Treat gradient segment exents as [left, right) ranges, instead of
[left, right], so that they don't overlap, and each point
corresponds to a unique color.
Perform less comparisons in gimp_gradient_get_segment_at_internal().
... which merges a segment range into a single segment, that spans
the entire range, and has the same endpoint colors. The merged
segment's midpoint is at its center, and its blend function and
coloring type are those of the range's segments if they're uniform,
or the default ones otherwise.
... which returns the flat (context-independent) left and right
colors of a egment. Replace code that calculates the flat color
explicitly with calls to these functions.
An internal gradient object, that will be used by the blend tool
when editing a gradient. By default, the active gradient will not
be edited directly, but rather, upon editing, the active gradient's
contents will be copied to the custom gradient, which will then
become the active gradient and be edited. This allows editing both
writable and nonwritable gradients without modifying them, and
without having to duplicate them.
... which copies the contents of a GimpData into an existing GimpData,
without creating a new instance.
Add a copy() virtual function to GimpData, which subclasses can
override to implement copying; gimp_data_copy() may only be called
for types that implement copy(). Keep the duplicate() virtual
function around, but provide a default implementation that creates
a new object of the source type, and uses copy() to copy the source
object into it.
Add parameters, controlling the behavior and appearance of sliders,
to GimpControllerSlider. The macro GIMP_CONTROLLER_SLIDER_DEFAULT
expands to a nonmodifiable lvalue of type GimpControllerSlider,
whose members are initialized with the most common default values.
Handle the new parameters in GimpToolLine. A slider using the new
"autohide" mode is only visible when selected, or when the cursor
is close enough to the line, between the slider's min and max
values, and no other handle is grabbed or hovered-over.
... which is emitted when a handle is single/double/tripple clicked.
The signal handler returns a boolean value. A return value of TRUE
stops further event processing, while a return value of FALSE allows
it.
The signal is emitted when a slider is dragged away from the line,
and will be removed when the button is released, and when the
slider is dragged back to the vicinity of the line, and won't be
removed. The last parameter of the signal is a boolean flag
differentiating between the two cases.
Note that a remove-slider signal may be emitted without a preceeding
prepare-to-remove-slider signal, however, is a prepare-to-remove-
slider signal is emitted with a TRUE last parameter, it must be
eventually followed by a remove-slider signal, or by another
prepare-to-remove-slider signal with a FALSE last parameter.
Add support for adding and removing sliders to/from a GimpToolLine,
using three new signals:
- can-add-slider: Takes a double argument in the range [0,1],
indicating a location along the line, and returns a boolean
value, indicating whether a slider can be added at that
location.
- add-slider: Takes a double argument in the range [0,1],
indicating a location along the line, for which can-add-slider
returned TRUE. In response, should add a new slider at that
location, and return its index, or a negative value if no
slider was added.
- remove-slider: Takes a slider index. In response, may remove
the slider.
On the UI side, when the cursor is close enough to the line, but
not within the hit area of an existing handle, GimpToolLine checks
if a slider can be added at the cursor position, using can-add-
slider. If a slider can be added, a dashed circle appears at the
cursor position along the line, indicating where a slider will be
added. The cursor is added by clicking, which emits an add-slider
signal; if the signal returns a slider index, the new slider is
selected, and can be subsequently dragged.
Removing a slider is done by either selecting the slider and
pressing backspace (or delete, although we don't actually forward
it to the tool atm,) or by "tearing" the slider: when dragging
the slider, if the cursor is far enough from the liner, a dashed
circle appears around the slider, and releasing the mouse removes
the slider.
