In the line-art async function, pass ownership over the resulting
buffer to the async object, so that the buffer is properly freed in
case the async in canceled after line-art computation is complete,
but before the completion callback is called.
Also, clear the tool's async pointer in the completion callback, to
avoid leaking the last issued async.
The "update" signal on drawable or projection can actually be emitted
many times for a single painting event. Just add new signals ("painted"
on GimpDrawable and "rendered" on GimpProjection) which are emitted once
for a single update (from user point of view), at the end, after actual
rendering is done (i.e. after the various "update" signals).
Also better support the sample merge vs current drawable paths for
bucket fill.
Since commit b00037b850, erosion size is not used anymore, as this step
has been removed, and the end point detection now uses local thickness
of strokes instead.
Other bucket fills are now done as filter until committed, but basic
selection fill is still done automatically. So let's make sure the
canvas is updated immediately (as it used to be before my changes).
In the scale tool, when the "around center" option is toggled,
scale the item around its center not only through canvas
interaction, but also when entering width/height values through the
tool GUI.
I have not added all the options for this new tool yet, but this sets
the base. I also added a bit of TODO for several places where we need to
make it settable, in particular the fuzzy select tool, but also simply
PDB calls (this will need to be a PDB context settings.
Maybe also I will want to make some LineArtOptions struct in order not
to have infinite list of parameters to functions. And at some point, it
may also be worth splitting a bit process with other type of
selection/fill (since they barely share any settings anyway).
Finally I take the opportunity to document a little more the parameters
to gimp_lineart_close(), which can still be improved later (I should
have documented these straight away when I re-implemented this all from
G'Mic code, as I am a bit fuzzy on some details now and will need to
re-understand code).
Rather than just having a click interaction, let's allow to "paint" with
the bucket fill. This is very useful for the new "line art" colorization
since it tends to over-segment the drawing. Therefore being able to
stroke through the canvas (rather than click, up, move, click, etc.)
makes the process much simpler. This is also faster since we don't have
to recompute the line art while a filling is in-progress.
Note that this new behavior is not only for the line art mode, but also
any other fill criterion, for which it can also be useful.
Last change of behavior as a side effect: it is possible to cancel the
tool changes the usual GIMP way (for instance by right clicking when
releasing the mouse button).
Right now, this is mostly meaningless as it is still done sequentially.
But I am mostly preparing the field to pre-compute the line art as
background thread.
Replace GimpTransformTool's 'drawable' field with an 'item' field,
and have GimpTransformGridTool set it to the active item, to which
the transformation is applied, during its initialization. In
gimp_transform_tool_get_active_item(), return the value of the
transform tool's 'item' field, if not NULL, instead of the image's
active item. This makes sure we apply that transform-grid tools
apply the transformation for the item for which they were
activated, even if the image's active item has changed.
In the warp tool, don't commit a trivial (empty) transform. This
is especially important now that exiting the tool through undo
causes it to get comitted (... with a trivial transform).
... changing layers and warping layer B
Add a new GimpToolControl::dirty_action field, which specifies the
tool action to perform when the a dirty event matching the tool
control's dirty mask occurs; this field defaults to HALT. Apply
this action to the active tool in tool-manager in response to a
matching dirty event, instead of unconditionally halting the tool.
Likewise, use this action to stop the active tool in response to a
button-press event on a different drawable in the same image.
Set the dirty action of the gradient and warp tools to COMMIT, so
that they get comitted, rather than stopped, in cases such as
switching layers (including switching to/from quick-mask mode),
and, for the warp tool, changing the selection.
... the XCF file
Add a "saving" signal to GimpImage, which is emitted when the image
is about to be saved or exported (but before it's actually saved/
exported). Connect to this signal in tool-manager, and commit the
current tool in response (unless its GimpToolControl::preserve is
TRUE).
We currently construct the tool-options GUI for all the tools at
startup, which takes a significant amount of time. Instead,
only register the GUI construction function with the tool-options
object, using the new gimp_tools_set_tool_options_gui_func()
function, and use the registered function to construct the GUI when
actually needed.
... after erasing all points
When erasing the last remaining point in the iscissors tool, halt
the tool, rather than leaving the tool active with an empty curve,
which it is not prepared to handle, and which results in a segfault
once trying to add a new point.
Additionally, when erasing the last remaining segment (i.e., the
two last remaining points), don't erase the entire segment (i.e.,
both points), but rather convert the segment to its initial point,
so that, in effect, we only erase the last point of the segment.
This reverts commit d31725a9cd.
This option is not very useful. In order to do actual perspective
correction, we need more information, such as the scene's vanishing
point and the camera's focal length. The measure tool is probably
not the right place to do all that. Let's simply revert this.
Add a boolean "perspective correction" option to the measure tool.
When toggled, the measure tool uses two compass widgets, instead of
one. Straightening the active item in this mode results a
perspective transform that straightens both lines simultaneously,
keeping their origin fixed.
The information displayed in the info window/statusbar always
refers to the currently-focused compass.
In GimpTransformTools, precalculate the resulting size of the
transformed item(s), and request confirmation if the size grows to
over 10 times the size of the image (in either dimension). This
protects against transformations that can result in suprprisingly
large items, such as inverted transformations, and, specifically,
perspective-correction transformations performed using the measure
tool, which will be added in the following commits.
... and G_TYPE_INSTANCE_GET_PRIVATE()
g_type_class_add_private() and G_TYPE_INSTANCE_GET_PRIVATE() were
deprecated in GLib 2.58. Instead, use
G_DEFINE_[ABSTRACT_]TYPE_WITH_PRIVATE(), and
G_ADD_PRIVATE[_DYNAMIC](), and the implictly-defined
foo_get_instance_private() functions, all of which are available in
the GLib versions we depend on.
This commit only covers types registered using one of the
G_DEFINE_FOO() macros (i.e., most types), but not types with a
custom registration function, of which we still have a few -- GLib
currently only provides a (non-deprecated) public API for adding a
private struct using the G_DEFINE_FOO() macros.
Note that this commit was 99% auto-generated (because I'm not
*that* crazy :), so if there are any style mismatches... we'll have
to live with them for now.
When moving a text layer using the text tool (through alt+drag),
don't change the layer's box mode to "fixed", which is unnecessary,
since the layer's size isn't affected.
While editing a text layer with the text tool, update the layer's
frame when the layer moves, which most notably happens when
undoing/redoing a move operation while the text tool is active.
The various functions of the text tool currently block and unblock
drawing (through gimp_text_tool_[un]block_drawing()) implicitly,
and in a non-symmetric fashion, which makes the tool's logic rather
fragile. Instead, require blocking/unblocking to be done
symmetrically, and explicitly block/unblock drawing as necessary in
all functions.
In all the selection tools, show an error (and a BAD cursor
modifier) wheh starting a selection, if the current selection is
empty, and the tool is in SUBTRACT or INTERSECT mode (in which
case, the selection has no effect).
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().
... 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.
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.
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.)
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.
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).
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 b07f60d06f
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
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.
All babl formats now have a space equivalent to a color profile,
determining the format's primaries and TRCs. This commit makes GIMP
aware of this.
libgimp:
- enum GimpPrecision: rename GAMMA values to NON_LINEAR and keep GAMMA
as deprecated aliases, add PERCEPTUAL values so we now have LINEAR,
NON_LINEAR and PERCPTUAL for each encoding, matching the babl
encoding variants RGB, R'G'B' and R~G~B~.
- gimp_color_transform_can_gegl_copy() now returns TRUE if both
profiles can return a babl space, increasing the amount of fast babl
color conversions significantly.
- TODO: no solution yet for getting libgimp drawable proxy buffers in
the right format with space.
plug-ins:
- follow the GimpPrecision change.
- TODO: everything else unchanged and partly broken or sub-optimal,
like setting a new image's color profile too late.
app:
- add enum GimpTRCType { LINEAR, NON_LINEAR, PERCEPTUAL } as
replacement for all "linear" booleans.
- change gimp-babl functions to take babl spaces and GimpTRCType
parameters and support all sorts of new perceptual ~ formats.
- a lot of places changed in the early days of goat invasion didn't
take advantage of gimp-babl utility functions and constructed
formats manually. They all needed revisiting and many now use much
simpler code calling gimp-babl API.
- change gimp_babl_format_get_color_profile() to really extract a
newly allocated color profile from the format, and add
gimp_babl_get_builtin_color_profile() which does the same as
gimp_babl_format_get_color_profile() did before. Visited all callers
to decide whether they are looking for the format's actual profile,
or for one of the builtin profiles, simplifying code that only needs
builtin profiles.
- drawables have a new get_space_api(), get_linear() is now get_trc().
- images now have a "layer space" and an API to get it,
gimp_image_get_layer_format() returns formats in that space.
- an image's layer space is created from the image's color profile,
change gimpimage-color-profile to deal with that correctly
- change many babl_format() calls to babl_format_with_space() and take
the space from passed formats or drawables
- add function gimp_layer_fix_format_space() which replaces the
layer's buffer with one that has the image's layer format, but
doesn't change pixel values
- use gimp_layer_fix_format_space() to make sure layers loaded from
XCF and created by plug-ins have the right space when added to the
image, because it's impossible to always assign the right space upon
layer creation
- "assign color profile" and "discard color profile" now require use
of gimp_layer_fix_format_space() too because the profile is now
embedded in all formats via the space. Add
gimp_image_assign_color_profile() which does all that and call it
instead of a simple gimp_image_set_color_profile(), also from the
PDB set-color-profile functions, which are essentially "assign" and
"discard" calls.
- generally, make sure a new image's color profile is set before
adding layers to it, gimp_image_set_color_profile() is more than
before considered know-what-you-are-doing API.
- take special precaution in all places that call
gimp_drawable_convert_type(), we now must pass a new_profile from
all callers that convert layers within the same image (such as
image_convert_type, image_convert_precision), because the layer's
new space can't be determined from the image's layer format during
the call.
- change all "linear" properties to "trc", in all config objects like
for levels and curves, in the histogram, in the widgets. This results
in some GUI that now has three choices instead of two.
TODO: we might want to reduce that back to two later.
- keep "linear" boolean properties around as compat if needed for file
pasring, but always convert the parsed parsed boolean to
GimpTRCType.
- TODO: the image's "enable color management" switch is currently
broken, will fix that in another commit.
... 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.
Bind the "orientation" property of the measure-tool options to the
tool's compass widget's "orientation" property, instead of manually
synchronizing their values.
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.
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.
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.
Ell