Move the call to gimp_filter_tool_disable_color_picking() from the
filter-tool's dialog "unmap" handler to gimp_filter_tool_halt().
Since commit ec80a88513, we
explicitly destroy the GUI when halting the filter tool, which
happens before the dialog's unmap handler is called, which could
potentially result in a dangling pointer to the active color-picker
widget in gimp_filter_tool_disable_color_picking().
(cherry picked from commit 072d6b0d12)
... 100% position anymore
In GimpGuideTool, use a closed [0, max_position] range as the
allowable range for new/repositioned guides (where max_position is
either the image's width or height), so that guides can be placed
at the right/bottom edge of the image.
(cherry picked from commit 547190faa8)
In gimp_filter_tool_halt(), explicitly clear the GUI container
before clearing filter_tool->config, since the tool might be halted
during the GUI dialog's delete event, in which case the GUI will
only be implicitly destroyed *after* the function returns. The
destruction of the GUI might fire signals whose handlers rely on
filter_tool->config, so we need to make sure it happens while it's
still alive.
In particular, this fixes a CRITICAL in the threshold tool, which
occurs due to the histogram view's "range-changhed" signal being
fired during its destruction, and its handler accessing
filter_tool->config.
(cherry picked from commit ec80a88513)
In gimp_transform_tool_transform(), use "active_item", instead of
"tool->drawable", when cutting/pasting the selected portion of a
layer for transformation. The latter is a remnant of the old
transform-tool code, and is not guaranteed to be correspond to the
correct drawable, or even to a valid drawable (i.e., it can
potentially produce wrong results, or segfault.)
(cherry picked from commit 9420805525)
Fixed by implementing Massimo's two findings:
gimp_operation_cage_transform_process(): if aux_buf is NULL, bail out
after initializing out_buf with identity vectors, fixes the crash.
gimp_cage_tool_create_filter(): set the drawable filter's region to
GIMP_FILTER_REGION_DRAWABLE, fixes offset when there is a selection.
(cherry picked from commit 49dfc6143d)
Adding spaces between function names and parenthese.
I would normally have just amended the contributed patches and pushed,
but gitlab is making our review process over-complicated with many
roundtrips with contributors, and review quality drops. Stating it here
for the records!
See commit 70945b8960 (where this cleaning
should have directly been done).
(cherry picked from commit 5c56f8cb3a)
anchor of LTR is top-left corner.
anchor of TTB-RTL is top-right cornner.
anchor of TTB-LTR is top-left cornner.
(cherry picked from commit 70945b8960)
Squashed commit of the following:
commit ee1ff7d502658cfa1248a13a3f0348495db07eda
Author: ONO Yoshio <ohtsuka.yoshio@gmail.com>
Date: Sun Jul 29 00:31:47 2018 +0900
Fixed that gimp-text-dir-ttb-* icons are lacked in Symbolic.
commit d87d012d697628da28fe90199cc04b95b72ba8ef
Author: ONO Yoshio <ohtsuka.yoshio@gmail.com>
Date: Sat Jul 28 16:23:10 2018 +0900
Fix a typo.
commit cf0238bf7df56c384cdf3b7ec69557d14740f853
Author: ONO Yoshio <ohtsuka.yoshio@gmail.com>
Date: Sat Jul 28 15:50:57 2018 +0900
Fixed seg fault error.
commit b07f60d06fa1a753fda5b4d46af01698c344154e
Author: ONO Yoshio <ohtsuka.yoshio@gmail.com>
Date: Fri Jul 27 17:15:34 2018 +0900
Add support for vertical text writing.
https://gitlab.gnome.org/GNOME/gimp/issues/641
(cherry picked from commit 587d9bbb03)
In GimpFilterTool, bind the controller's lifetime to the lifetime
of the config object, rather than to the lifetime of the
corresponding tool widget; make the controller's widget pointer a
weak pointer to the widget, and bail out of the controller "set()"
functions when the widget pointer is NULL.
This fixes an issue arising when the properties of a config object
that outlives the widget change after the widget had died,
triggering a call to the controller's set() function, resulting in
a segafult when trying to access the widget.
(cherry picked from commit 78abe756f1)
... from layer context menu
In gimp_text_tool_set_layer(), do nothing if the input layer is the
currently-edited layer, otherwise we get a CRITICAL.
(cherry picked from commit 6b1d77b11c)
... does not restore the measure points
Halt the measure tool after straightening, thus removing the
expectation that undoing the operation should restore the original
points.
Halting the tool, rather than making undo work "as expected",
sidesteps several issues:
- Implementing undo correctly is tricky, since image-undo and
tool-undo are handled separately.
- In fact, the measure tool doesn't provide tool-undo, so that
image edits can be undone while the tool is active without
affecting the tool, and it's not clear that we want to change
this behavior. However, this makes undoing a straighten
operation a special case, and it's not entirely clear what the
behavior should be when undoing other kinds of transformations,
or when the measure points had changed since the straighten
operation.
- Perhaps most importantly, measure tool points are restricted to
the pixel grid, which means that when measuring an angle
against an orientation that's not fully horizontal or vertical
in image space (either using a 3-point angle, or when the
canvas is rotated), the resulting transformed point after
straightening doesn't generally land on the pixel grid, causing
it to be rounded, which can result in a non-zero angle after
the rotation. This is especially ugly, since clicking
"straighten" again at this point would cause another non-
trivial rotation.
(cherry picked from commit 2e08c9164a)
Bind the "orientation" property of the measure-tool options to the
tool's compass widget's "orientation" property, instead of manually
synchronizing their values.
(cherry picked from commit 7a91aabf37)
Add an "orientation" option to the measure tool, corresponding to
the "orientation" property of GimpToolCompass (i.e., it controls
the orientation against which the angle is measured, when not in 3-
point mode.) The orientation is "auto" by default, so that the
angle is always <= 45 deg. Note that the "orientation" option
affects the tool's "straighten" function, so that the layer is
rotated toward the current orientation.
Use the "pixel-angle" and "unit-angle" properies of
GimpToolCompass to read the measured angle, instead of duplicating
the angle-measurement logic, in particular, so that we benefit from
the improvements/fixes of the previous commit.
(cherry picked from commit cb3b7a1ba5)
Add an "orientation" property to GimpToolCompass, which can be one
of "auto", "horizontal", or "vertical", and which controls the
orientation of the line against which the angle is measured, when
not in 3-point mode (previously, the line would always be
horizontal.) When "orientation" is "auto", the orientation is
automatically set to either horizontal or vertical, such that the
measured angle is <= 45 deg.
Keep the line horizontal, or vertical, in display-space, rather
than in image-space, so that the compass works correctly even when
the canvas is rotated and/or flipped.
Fix the compass's behavior when the image's horizontal and vertical
resolutions are different, both with and without dot-for-dot.
Add "pixel-angle" and "unit-angle" read-only properties, which
return the measured angle either with or without taking the image's
resolution into account, respectively. These properties will be
used by the measure tool in the next commit, instead of having it
implement its own angle calculation.
(cherry picked from commit d2f33cf1be)
Fix gimp_constrain_line() and friends to properly constrain line
angles when the image's horizontal and vertical resolutions are
different, and dot-for-dot is disabled.
(cherry picked from commit 4fefab1798)
This is just some preparation for fixing issue #1805, but actually
"target" is a much better name so I went the full way and also changed
GUI labels and the color picker tool options config property
accordingly.
If anyone notices at all, how horrible is it to lose your saved pick
target...
(cherry picked from commit b140b283dc)
...and successfully fails
Commit d2ad2928 removed "gradient-repeat" from GimpPaintOptions, not
considering that it is also used in the PDB.
Move "gradient-repeat" from GimpGradientOptions back to
GimpPaintOptions, and add a comment that it is only used by the
gradient tool, not for painting.
(cherry picked from commit c3d37140eb)
and remove all other tool options parent setting/unsetting and
property copying code. Also select a tool at the end of
tool_manager_init() so it is in sync with what the tool options
manager does.
(cherry picked from commit 37f69457b7)
tool_options_manager_tool_changed(): also copy the non-global paint
options of the new tool to the global paint options, so they get used
when "global_foo" is enabled.
(cherry picked from commit 1b858eb4ad)
tool_options_manager_paint_options_notify(): sync properties between
tool paint options and global paint options if the property is global
*or* the active tool is involved.
tool_options_manager_global_notify(): don't mess with the active
tool's connection to the user context or its properties at all, it is
always fully connected to the user context anyway.
(cherry picked from commit 54257da7c4)
The way we currently manage tool options, and particularly copy things
around for "global_brush", "global_pattern" etc. sucks, is spread
across files, happens only on tool change, is thus buggy and leads to
all sorts of small inconsistencies.
This new manager will replace all of that stuff, and it does it in one
place, and will keep the user context, the global paint options, and
all tool options connected permanently, and only connect/disconnect
things when settings change, so everything is always in a consistent
state.
Pushed for review only, nothing is used yet.
(cherry picked from commit ef952f2926)
The "move-current" flag does not apply to selection mode and our current
code was simply setting the radio buttons insensitive while showing the
same labels on both buttons. This was not wrong per-se, yet very
confusing.
Instead let's just hide the radio buttons in selection mode, and update
the option title to "Move selection" (old label of both buttons) to keep
this mode as understandable as possible.
(cherry picked from commit 7cbbb8cba8)
We should not have essential signal connections (such as setting tool
options from brush properties) implemented in the tool options GUI
files, because they are not active until the options GUI is created.
Also, that magic is simply too hidden in the options GUI files.
Move the signal connections and the brush property copying code to
gimppaintoptions.c where is can also be done cleaner.
However, this must only be done for the main tool options instance
that is used for the GUI. Therefore, add a "gui_mode" boolean to
GimpToolOptions and set it to TRUE for all main tool options.
(this is ugly, but much less ugly and much less hidden than all the
places where code lives (like tool_manager.c) that can now be moved
into GimpToolOptions and its subclasses, and implemented cleanly
there).
(cherry picked from commit cb0e6c65d0)
When using the color-picker tool's info window, set the tool's
display when a color is picked, and the gui is updated, so that we
properly halt the tool when the display is closed. Otherwise, we
may segfault.
(cherry picked from commit 335023b127)
In GimpScaleTool, fix scaling around the center-point, and make
sure the width and height are always >= 1 when updating the
transformation in response to a widget change.
(cherry picked from commit 1516bfc14b)
Get rid of GimpTransformGridTool::recalc_matrix() and
gimp_transform_grid_tool_recalc_matrix(), and have
GimpTransformGridTool and its subclasses use
GimpTransformTool::recalc_matrix() and
gimp_transform_tool_recalc_matrix() directly instead.
In order to break the GimpToolWidget::changed/
GimpTransformTool::recalc_matrix() loop, add a
GimpTransformGridTool::update_widget() vfunc, which subclasses
should override to update their tool-widget (instead of doing this
in ::recalc_matrix()), and ::widget_changed(), which is called when
the tool-widget changes (and which subclasses should override
instead of connecting to the tool-widget's "changed" signal
directly.) GimpTransformGridTool calls these functions as
necessary, instead of relying on extra parameters passed to
recalc_matrix().
Adapt all the direct and indirect subclasses of
GimpTransformGridTool to the change.
(cherry picked from commit 6a3fc6c1b9)
In GimpTool, always clear tool->drawable upon halting, even for
tools that don't use it explicitly.
GimpTool sets tool->drawable in its default button_press()
implementation, and we potentially access it in
gimp_display_shell_initialize_tool(), so failing to clear it when
halting the tool may leave it as a dangling pointer, which can
result in a segfault when trying to initialize the tool in the
above function. In particular, this happens with the iscissors
tool.
(cherry picked from commit 58c96f596e)
Make gimp_free_select_tool_halt() protected, and call it in
gimp_foreground_select_tool_set_trimap(), so that the free-select
subobject of the foreground-select tool is properly shut down
before switching to trimap mode. In particular, this clears the
free-select tool widget at the right point; failing to do this
leads to CRITICALs later on.
(cherry picked from commit e15733236c)
Last commit reintroduced this bug.
Allow transforming invisible layers using transform-grid tools, by
adding a 'drawable' member to GimpTransformTool, and setting/
clearing it when initializing/halting a GimpTransformTool. In
gimp_transform_tool_check_active_item(), skip the visibility check
if the active item equals the GimpTransformTool's 'drawable'
member.
(cherry picked from commit cea6f1dc73)
Split gimp_transform_tool_get_active_item() into two functions:
gimp_transform_tool_get_active_item(), which returns the item
without checking for errors, and
gimp_transform_tool_check_active_item(), which returns the active
item while checking for errors. Adapt the rest of the code to the
change.
Remove the invisible_layer_ok parameter of
gimp_transform_tool_check_active_item(), and always return an error
when the active layer is invisible. This causes the flip and
measure tools to correctly reject invisible layers. Un-hide the
active item in GimpTransformGridTool before transforming, to avoid
rejecting layers that were hidden by the tool.
(cherry picked from commit 360b25b9a8)
Derive GimpMeasureTool from GimpTransformTool (and
GimpMeasureOptions from GimpTransformOptions), so that we can reuse
GimpTransformTool's logic for the "straighten" function. This
simplifies the code, aligns the measure tool with the rest of the
transform tools in terms of transform-related options (it can now
transform selections and paths, in addition to layers, and the
resampling method and clipping behavior are adjustable,) and fixes
straightening of layer groups.
Rename the function from "auto straighten" to just "straighten".
Don't resize the canvas after straightening. Since we only
transform the active layer, and not the entire image, resizing the
canvas doesn't make much sense.
When in 3-point mode, rotate the second point toward the third
point, rather than toward the x-axis.
(cherry picked from commit b0cf2e435a)
While most of our transform tools use an interactive transform
grid, and have similar behavior, the flip tool is an odd one out.
The new "auto straighten" function of the measure tool introduces
another tool that performs transformations, while not behaving like
the rest of the transform tools.
Factor out the parts of GimpTransformTool that handle user
interaction into GimpTransformGridTool (with corresponding
GimpTransformGridOptions, and GimpTransformGridToolUndo), and only
leave the basic transform functionality and options in
GimpTransformTool (and GimpTransformOptions).
Derive all the transform tools (and transform-tool base classes)
that previously derived from GimpTransformTool, from
GimpTransformGridTool. The one exception is GimpFlipTool, which
still derives from GimpTransformTool directly. The next commit
will derive GimpMeasureTool from GimpTransformTool as well.
Add GimpPaintTool::paint_[xy] members, and periodically assign the
paint core's current coords to them in
gimp_paint_tool_paint_timeout(), while the main thread and the
paint thread are synchronized, during painting.
In gimp_paint_tool_draw(), fetch the current coords for the brush
outline from the above members during painting, instead of directly
from the paint core, to avoid a race condition with the paint
thread, so that we always use the correct coordinates at the time
the paint buffer was flushed back to the drawable.
(cherry picked from commit 5c17d2a43b)
Instead just transform the measurement extremities appropriately to
still map to the same points.
To do so, I also added out parameters to gimp_image_resize_to_layers()
so that calling code can get offsets from old origin (as well as new
image dimensions).
(cherry picked from commit d56a8d439e)
In particular, this tool should not make huge rotation where the top
ends up in the bottom and it should not depend on whether we started the
measure tool from the left, right, bottom or top. This is fixed by using
atan() instead of atan2().
Also make a proper tooltip text. Help id is unneeded most likely though.
Finally do some cleaning and alignment.
(cherry picked from commit ba1d937dfb)
... which is similar to the TRANSFORM_GRID controller, supporting
multiple transformation matrices.
Implement the TRANSFORM_GRIDS controller in GimpFilterTool, using
the new GimpToolWidgetGroup to display multiple transform grids.
(cherry picked from commit 5e953ece85)
This is mostly core code which we want to keep in sync with master as
long as possible, so I picked this one even though not strictly
neccessary.
(cherry picked from commit 1b7d63cce9)
In the threshold and levels tools, use gimp_wait() to wait for
histogram calculation to complete before applying auto-adjustment,
so that a message is displayed in the meantime. Allow the
operation to be canceled, in which case we simply abort the auto-
adjustment, but let the histogram calculation continue.
While fonts are loading, show a GimpBusyBox with an appropriate
message above the text tool options, and make the options
themselves insensitive, and in font views, such as in the fonts
dialog (through gimp_container_editor_bind_to_async_set(), added in
the previous commit).
We already avoid rendering text layers while fonts are loading,
showing an appropriate message, but this will soon be replaced with
waiting for the fonts to finish loading.
Instead, don't allow the text tool to start at all while the fonts
are loading (showing an appropriate tool message, and a BAD cursor
modifier), and halt the tool when reloading fonts if it's already
started.
Have GimpAsync implement the GimpWaitable and GimpCancelable
interfaces, added in the previous two commits, instead of providing
its own public version of the corresponding functions.
Add gimp_async_cancel_and_wait() as a convenience function for both
canceling an async operation, and waiting for it to complete.
Adapt the rest of the code to the change.
(cherry picked from commit e2c56ef407)
...in weird ways
In gimp_rectangle_tool_button_press(), when the press triggers a
GimpEditSelectionTool operation (like moving a floating selection),
make sure we don't call COMMIT on a zero-size rectangle, because that
would get special treatment by commit(). Instead, CANCEL a zero-size
rectangle so stuff behaves as if it has never been there.
That was an obvious faux ami with French.
Status changed to "press Enter to refine", with the requirement of
staying not too long (this is a status message, not documentation), and
that also announces what will be the next step.
It is not obvious that you have to hit Enter to validate the first step
of Foreground Selection tool, i.e. the rough free selection. Adding this
information in status message.
Since Enter would only work once the free selection is closed or that
you have at least 3 points (then Enter closes the selection for you), I
also add gimp_free_select_tool_get_n_points() so that we can know how
many points were created from the Foreground Select tool, and only
update the status message when relevant.
In GimpCurvesTool, calculate the histogram of the target drawable
asynchronously, rather than synchronously, to avoid blocking the UI
while the histogram is calculated.
In GimpLevelsTool, calculate the histogram of the target drawable
asynchronously, rather than synchronously, to avoid blocking the UI
while the histogram is calculated.
In GimpThresholdTool, calculate the histogram of the target
drawable asynchronously, rather than synchronously, to avoid
blocking the UI while the histogram is calculated.
Additionally, fix the initial "low" threshold value for > 8bpc
images (127/255 => 0.5).
In the gradient-tool editor, when responding to an endpoint size-
entry "changed" signal, make sure there is a selected handle, and
bail otherwise. We can receive a "changed" signal without a
selected handle, if the endpoint is deselected while a change to
the size-entry's value is in progress, causing the the tool GUI to
be unmapped, and the changed value to be committed.
When in anti-erase mode, always return TRUE, since it's only
effective when the drawable has an alpha channel.
Also, remove an unnecessary #include in gimp_ink_tool.c.
Add a GimpPaintTool::is_alpha_only() virtual function, which
subclasses can override to indicate whether painting only affects
the alpha channel (assuming FALSE by default). Override the
function in Gimp{PaintBrush,Ink,Clone}Tool, returning TRUE when the
current paint mode only affects the alpha (as per
gimp_layer_mode_is_alpha_only(); see the previous commit,) and in
GimpEraserTool, returning TRUE when the target drawable has an
alpha channel.
When the function returns TRUE, and the target drawable doesn't
have an alpha channel, or the alpha channel is locked, show a BAD
cursor modifier, and raise an appropriate warning when attempting
to paint.
In GimpTextTool, when starting the editor in response to a button
press, always set the text tool's image first, so that the style
editor picks the correct resolution for the text-size entry.
Currently the image is only set when clicking inside the active
drawable's bounds.
gimp_rectangle_select_tool_cursor_update(): always set a cursor and
cursor modifier even if no GimpToolRectangle widget exists, so we are
not stuck with the last set cursor after committing or halting the
tool.
Add gimp_drawable_gradient_adjust_coords(), which adjusts the
gradient segment coords according to the gradient type, so that, in
cases where the gradient span is unrelated to the segment length,
the gradient cache (in GimpOperationGradient) is big enough not to
produce banding. Use the new function in gimp_drawable_gradient()
and in the gradient tool, instead of duplicating the logic.
Move the shapreburst coordinate-adjustment logic to the new
function, and add appropriate logic for conical gradients.
Remove the code that avoids using the gradient cache for conical
gradients from GimpOperationGradient.
In the various types of fill operations, and in fade operations,
use the paint composite-mode of the current paint mode, which is
the composite mode we use during painting, instead of AUTO, which
results in the default mode we use for layer compositing. This
effectively means that filling using any non-legacy, non-
subtractive mode can paint over transparent areas, rather than
being limited to nontransparent areas.
In gimp_text_tool_connect(), when auto-removing empty text layers upon
text layer or tool change, make sure we don't try to remove a layer
that has already been removed, which can happen if this function is
reached *because* somehow the layer was removed externally (e.g. by
the user in the layers dialog).
... when using default aspect ratio
The call to
gimp_{crop,rectangle_select}_tool_update_option_defaults() when
starting the crop/rectangle-select tools seems to no longer be
necessary, while it overrides user modification to the default
ratio's landscape/portrait orinetation (which only really matters
for the crop tool, since the rectangle-select tools' default ratio
is 1:1). Fix this by simply removing the call.
Commit ddfc7715cb changed the
airbrush periodic stamp behavior, so that instead of using the main
brush, it issued a full MOTION event, potentially using a different
brush when using a GIH brush.
Fix this, by renaming the "timeout" signal of GimpAirbrush to
"stamp", and by adding a new gimp_airbrush_stamp() function, which
should be used for painting the periodic airbrush dab in response,
instead of calling gimp_paint_core_paint() directly, and which
calls gimp_airbrush_paint() instead, as the old code did.
In order to call this function from the paint thread, we replace
the various gimp_paint_tool_paint_core_foo() functions, introduced
in the above commit, with a generic gimp_paint_tool_paint_push()
function, which takes a callback (and a data pointer) to run on the
paint thread, and queues it for execution (when not using the paint
thread, the function is called directly from the calling thread.)
...(Pixel, Position and Size, Alpha Channel) are enabled.
gimp_edit_selection_tool_translate(): add checks for locks and bail
out with a message if the item is NULL or locked.
gimp_move_tool_button_press(): refactor NULL and lock checks to look
more like the new code added above, and also check "lock-content" of
channels and masks: moving them changes their pixels.
GimpAirbrush currently performs painting and flushes the image on
its own during the airbrush timeout. This is unsafe w.r.t. the
paint thread, since the timeout is run on the main thread, while
paint commands should run on the paint thread.
Add a "timeout" signal to GimpAirbrush, and simply emit this signal
during the airbrush timeout, rather than actually painting.
Connect to this signal in GimpAirbrushTool, and use
gimppaintool-paint to perform the actual painting, in a thread-safe
manner (see the previous commit.)
We'd like subclasses of GimpPaintTool to be able to issue paint
commands to the tool's paint-core (in particular, see the next
commit.) Since paint commands should be executed on the paint
thread, the subclasses must not call the paint-core functions
directly, but should rather let gimppainttool-paint issue the
commands on their behalf.
Reorgainze gimppainttool-paint to make it usable for this purpose
by subclasses. In particular, add
gimp_paint_tool_paint_core_paint() and
gimp_paint_tool_paint_core_interpolate(), which call the
corresponding paint-core functions on the paint thread.
Additionally, rename the {start,end,flush}_paint() virtual
functions of GimpPaintTool to paint_{start,end,flush}(), and rename
gimp_paint_tool_is_painting() to gimp_paint_tool_paint_is_active(),
so that all the gimppainttool-paint-related stuff are grouped under
the same namespace.
Rename gimpblendtool{.c,-editor.{c,h}} to
gimpgradientool{.c,-editor.{c,h}}. Note that this commit only
renames the files; the actual changes are done in the next commit,
so that git doesn't consider them new files.
Partially revert commits 4f2e078ccb
and b0beb0197a, since the changes
they introduced to some of the renamed files were big enough for
git to consider them entirely new files, hence we lost their
history. The next few commits fix this.
This commit also partially or entirely undoes followup commits
5f6dfc7617,
c3f98cccbd,
6b0f5136e0,
and 3736bfd189, which will be
restored by the next few commits as well.
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.
Commit f5cb1fed85, 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.
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
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.
In GimpPaintTool, brush outline generation took place during
gimp_paint_tool_draw() even while painting. This function is run
concurrently with the paint thread. When using dynamics, this
introduced a race conidition between updating the brush mask in the
paint thread, and updating the brush boundary in the main thread.
Move brush outline generation during painting to
gimppainttool-paint.c, and perform it in the display-update
timeout, while the main thread and the paint thread are
synchronized.
After last commit, all paint tools work correctly with a separate
paint thread, so we can remove the option for specific paint tools
to opt out. Particularly, GimpMybrushTool now uses a separate
paint thread too.
Note that the separate paint thread can still be disabled through
the GIMP_NO_PAINT_THREAD environment variable.
Reorganize/clean up gimppainttool-paint. In particular, move all
paint-core interaction during painting to gimppainttool-paint.c, so
that we can have more control over what's going on; specifically,
enter the drawable into paint mode *before* starting the paint
core, so that it picks up the correct buffer. This fixes painting
with the paint thread using GimpApplicator, and enables us to use
the paint thread with GimpMybrushTool.
Add gimppainttool-paint.[ch], which takes care of painting during
motion events in GimpPaintTool. Perform the actual painting in a
separate thread, so that display updates, which can have a
significant synchronization overhead, don't stall painting.
Allow specific paint tools to opt-out of a separate paint thread,
and avoid it in GimpMybrushTool, since it doesn't seem to work.
The separate paint thread can be explicitly disabled by setting the
GIMP_NO_PAINT_THREAD environment variable.
Similar to commit 845eb522b6, I had a CRITICAL which happened on a
device_changed, triggering gimp_display_shell_update_focus(), this time
in focus in.
Commit fd6d4931c8 accidentally
introduced a bug that caused Wilber's eyes to misbehave. This
commit is an attempt to fix this issue. Unfortunately, it seems
like the bug can still be triggered through a certain sequence of
actions...
Add signal GimpTextBuffer::color-applied which is emitted when text is
inserted or when color is applied to a span of text.
In GimpTextTool, connect to the signal and update the global color
history.
Unrelated: rename gimp_text_tag_get_color() to get_fg_color() and add
boolean return values to get_fg_color() and get_fg_color() which
indicates if a color is set on the tag at all. This ended up unneeded
in the fix but is an improvement regardless.
Add a crop_input parameter to gimp_gegl_apply_[cached_]operation().
When TRUE, the functions crop the op's input to the destination
rect. This is particularly useful for functions that process the
entire input in one go (by means of get_cached_region()). See the
next commit.
Pass crop_input = FALSE at all call sites for now, to keep the
current behavior.
Focus change events were expecting the current tool control to be
inactive, which was the case most of the time. Yet with stylus, the
canvas was sometimes receiving GDK_BUTTON_PRESS events before
GDK_FOCUS_CHANGE. In particular the canvas was receiving a button press
before the focus out, then button release and focus in. Therefore by the
time the focus out event happens, the tool control is active, which
broke a few calls.
Therefore I add a few checks and returns immediately when
gimp_tool_control_is_active() return TRUE, especially since we also run
gimp_display_shell_update_focus() calls after a button press anyway so
the state should already be consistent.
Add a gimp_filter_tool_reset_widget() function, which resets the
tool widget associated with the filter's controller -- i.e., it
resets those properties of the widget that aren't controlled by the
op's properties to some "default" state. For most controller types
this is a NOP; for transform-grid controllers, we move the pivot
back to the center of the drawable, w.r.t. the current transform.
Call gimp_filter_tool_reset_widget() after resetting or reloading
the tool's config.
...only remembers horizontal radius, duplicates it for vertical
Keep a list of the GUI's chain buttons around. When changing the
entire config object like on reset or selecting saved settings, unlik
them all after remembering their "active" state, and after changing
the settings activate the ones that were active before, but only if
the values they link are still the same.
... when gradient_type >= GIMP_GRADIENT_SHAPEBURST_ANGULAR.
Our current GUI code for the Blend tool options disables the "Repeat"
widget with any of the shaped and spiral gradient types, which means (I
assume) no repeat mode is allowed on these gradients. Nevertheless it
was possible to change the repeat mode in another gradient type, then
switch to one of these and get the repeat processed even though the GUI
shows insensitive.
I could simply reset the repeat mode to GIMP_REPEAT_NONE when setting
one of these gradient types, but I think you'd want the repeat to stay
at its value (being insensitive is enough to mean whatever value is set
is not taken into account). So instead, I just unsync this specific
property when appropriate.
Note also I don't do this in the gimp:blend operation code because I am
not sure this specific behavior is meant to be a generic blend behavior
or just relative to the tool (render of the shaped gradients is barely
different with a repeat, but there is still a difference).
It seems old blend tool (from GIMP 2.8) was using manhattan distance,
whereas the new one uses euclidean. I guess there must be use cases for
both. In any case, it is a good idea to simply propose the option since
the property exists in the "gegl:distance-transform" operation.
See also bug 781621.
When starting the tool with one of the gradient types for which the
repeat option should be deactivated, it is not. Run the handler function
once at GUI creation.
Also compare the gradient type with an enum value, which makes the test
clearer than using an int.
... which allows ops to create a transform-grid widget, similar to
the unified-transform tool, which can be used to control a
transformation matrix.
Implement the transform-grid controller in GimpFilterTool.
... current aspect ratio
In gimp_{rectangle_select,crop}_tool_start(), move
GimpToolRectangle signal connection to the end of the function. In
particular, connect the signals *after* the call to
gimp_{rectangle_select,crop}_tool_update_option_defaults(), since
it may result in an emission of a "change-complete" signal, whose
handler calls the function again with ignore_pending == FALSE, which
would override the ratio set with ignore_pending == TRUE.
Don't choke when calling gimp_tool_rectangle_set_constraint() while
there's no active image, or while the active image has no active
layer, which can happen when updating the default aspect ratio of
the crop tool. This would previously result in CRITICALs.
Additionally, use weak pointers for the crop tool's current_image
and current_layer members, to avoid potential dangling pointers.
While not currently necessary, this makes the code less dependent
on the exact order of events.
... current aspect ratio
When updating the default aspect ratio of a widget-less crop tool,
construct a temporary GimpToolRectangle widget, so that we can use
it to call gimp_tool_rectangle_constraint_size_set() and pick the
correct ratio, instead of just bailing.
When halting the crop tool, update the default aspect ratio, which
now does the right thing, as per the above.
Update the default aspect ratio upon changes to the active layer of
the current image, and to the size of the active layer, which
affect the default aspect ratio when "current layer only" is
toggled.
... current aspect ratio
When starting the rectangle-select (and ellipse-select) tools,
properly reset their default aspect ratio to 1:1. This fixes an
issue where the tool would use the aspect ratio of the last
rectangle when there's no user-overriden aspect ratio specified.
This restores the 2.8 behavior, except for the fact that the aspect
ratio resets to 1:1 when the tool is commited (if there's no user-
overriden ratio), rather than keeping the aspect ratio of the last
rectangle (i.e. "Current"); in 2.8 this only happend when halting.
The current behavior seems more consistent anyway.
Set the scale of the GimpRectangleOptions highlight-opacity
spinscale to 100, so that the spinscale's range is 0-100, instead
of 0-1, like the rest of our opacity spinscales.
... a selection.
The crash was the result of an unmatched gimp_item_end_move() call,
which is an error. Add the matching gimp_item_start_move() call
when starting to drag a selection in GimpEditSelectionTool. Revert
last commit, so that unmatched gimp_layer_end_move() calls are not
silently ignored, and add a check instead.
which is just a #define to g_assert for now, but can now easily be
turned into something that does some nicer debugging using our new
stack trace infrastructure. This commit also reverts all constructed()
functions to use assert again.
A tool commit can be triggered in various cases, and the tool manager
relies on gimp_tool_has_display() to decide whether to run a tool
action. This function does much more than just checking GimpTool's
display. It also checks status_displays, and for a transform tool in
particular, it checks GimpDrawTool's display. This may be right for
other tools (I have no idea), so I can't just change this function.
Anyway we have to assume it is not a programming error if a transform
tool gets a COMMIT action while display is NULL (i.e. tool is halted).
When this happens, let's simply ignore.
This fixes the edge case raised by Ell, in comment 2 of bug 793150: when
an image has no layer, transform tools can't work and display is NULL.
But it still outputs status messages and therefore status_displays is
not empty. So the tool manager will still run a COMMIT action, which is
not an error. We only have to discard such COMMIT silently.
Improving previous commit. Rather than calling:
> GIMP_TOOL_GET_CLASS (tool)->control (tool,
GIMP_TOOL_ACTION_HALT,
display)
> gimp_tool_clear_status()
... in the COMMIT action, which is basically what the HALT action does,
simply pass through from one case to the other. It also adds the call to
gimp_tool_control_halt() which is most likely right anyway since we are
halting the tool. This also makes the code consistent and any future
changes to HALT case will be directly enabled after COMMIT.
... 'GIMP_IS_DISPLAY (display)' failed.
This may happen when committing first a transform tool, then switching
to another tool. In this case, the tool manager will attempt to commit
again because gimp_tool_has_display() returns TRUE since status displays
were not cleared. Unfortunately transform tools don't handle very well
trying to commit when it was already done (hence both GimpTool and
GimpDrawTool displays are NULL).
The proposed solution is to clear the statuses after committing.
Add gimp_item_{start,end}_move(), and corresponding
GimpItem::{start,end}_move() virtual functions, which should be
called before/after "moving" the item (i.e., translating, scaling,
resizing, flipping, rotating, or transforming the item). Moves
performed between the outermost pair of start/end calls are treated
atomically.
What exactly does "treated atomically" entail depends on the
subclasses -- GimpItem doesn't provide a default implementation for
these functions, so the current commit doesn't change any behavior.
The next commit, which adds layer-mask support for group layers,
uses the functions to avoid cropping the mask too early while a
child is moving.
GimpItem calls {start,end}_move() in the various "move" functions
(gimp_item_{translate,scale,...}(), before performing the actual
operation. Additionally we call the functions in the
gimp_image_item_list_foo() functions, for each participating item,
so that the items are moved as a unit. We call the functions in
the various gimp_image_remove_foo() functions, since removing an
item may affect the size of its ancestors, and is therefore akin to
moving. We also call the functions in GimpEditSelectionTool, so
that the move tool moves items atomically while dragging.
This reverts 2069496af3 for
gimpmeasuretool.c, we can't use gimp_display_shell_get_line_status()
here because the angle to show is *not* the angle as shown in the
paint tools (between x1,y1 and x2,y2), it is determined by a possible
third point.
Also, the info window and the statusbar were using different
coordintates to detemine the line length. This would have been easily
fixable, but the wrong angle wasn't.
