Seems we were drawing marching ants for hidden tabs ever since the
introduction of SWM, which is both a horrible waste of CPU time, and
also makes all selections visible on all displays on GTK+ 3.x.
Implement GtkWidget::unmap() in GimpDisplayShell and stop the ants
when the shell is unmapped.
(cherry picked from commit 1d43e2ff37)
When re-activating an operation tool by clicking on a different
drawable while the tool is active, we re-call the corresponding
procedure to re-activate the tool, which implictly initializes it.
Avoid initializaing it explicitly in addition to that, since this
leads to the creation of a new config object by the filter tool,
while the GUI still refers to the old, now-dead, config object,
causing CRITICALs or segfaults when changing any parameter.
(cherry picked from commit a21667821c)
... 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.
(cherry picked from commit ed20393f0e)
When removing the focus widget of a GimpToolWidgetGroup, use the
last child, rather than the first child, as the new focus widget.
This plays nicer with auto-raise, and is probably better anyway.
(cherry picked from commit 24fb597196)
When a focused widget is added to a group, make it the new focus-
widget of the group, instead of unsetting its focus if another
widget already has focus.
When removing the focused widget from a group, set a different
widget as the group's focus widget (if one exists), instead of
unsetting the focus widget, so that nonempty groups always have a
focus widget.
(cherry picked from commit 95d2c92ff2)
In gimp_tool_widget_group_button_press(), explicitly call
gimp_tool_widget_group_hover() before forwarding the event to the
group's hover widget, so that the hover widget gets recalculated.
If a widget is added to the group as a result of a button-press
event, this guarantees that it gets considered as a target for the
same event.
(cherry picked from commit 5b217b3ad4)
... 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.
In GimpCanvasTransformPreview, add the necessary bits to the
preview graph so that, when transforming a layer, the layer's
opacity and mask are correctly applied to the preview. Note that
since we're still not rendering the preview as part of the image
graph, the output is not always accurate, but it should be good
enough in most cases.
(cherry picked from commit 2ac91e0fc3)
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 GimpToolCompass (and, as a consequence, in the measure tool),
update the measured angle when the shell is scaled, rotated, or
flipped, so that we always satisfy the compass's constrains, and
render correctly.
(cherry picked from commit a810c6b60b)
When using a GimpToolCompass in 3-point mode, add a small gap after
the angle arc to the line corresponding to the "second" non-origin
point, so that it's visually distinguishable from the line
corresponding to the "first" point. This has significance for the
measure tool, since it determines the direction of the rotation
when straightening the image (the first point is rotated toward the
second point.)
(cherry picked from commit 0f03f9e9f5)
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)
Put the center_image_on_size_allocate() code into the canvas'
size-allocate callbacck.
As a side effect we now have a flag in GimpDisplayShell which
indicates that there will be a size allocate before the next frame, so
simply skip drawing the canvas completely. This fixes new images
jumping around when they are first shown.
(cherry picked from commit c0480f502d)
(this fix is actually a side effect from fixing something else in
master)
Replace "Selection Bounding Box" by simply "Selection" and add a tooltip
to the frame that says it's the bounding box.
Addressed Issue #1223.
(cherry picked from commit 33d2595d22)
In GimpCanvasTransformPreview, when the image mask is not empty,
make sure to align it with the drawable using a gegl:translate
node, before combining both at the gegl:opacity node. Otherwise,
the mask is applied at the wrong offset when the drawable's offset
is not (0, 0).
(cherry picked from commit d3a3c35317)
In GimpToolRectangle, call gimp_tool_rectangle_update_options()
when the "[xy][12]" properties change, so that the "x", "y",
"width", and "height" properties are updated accordingly.
In particular, we set these properties when committing an empty
rectangle select tool, to init the rectangle to the current
selection bounds, and this call is necessary so that the "x", "y",
"width", and "height" tool options are properly updated as well.
(cherry picked from commit 47b7e7be7d)
GimpToolWidgetGroup is a tool widget acting as a container for
child widgets, multiplexing widget events and demultiplexing tool
events. It can be used by tools to display multiple widgets
simultaneously.
The group keeps track of the current focus widget, and hover
widget. Certain events are only dispatched to/forwarded from these
widgets.
The hover widget is determined by performing a hit test for all the
children, starting from the last child. The first widget returning
GIMP_HIT_DIRECT, if any, is selected as the hover widget;
otherwise, if the current focus widget returns GIMP_HIT_INDIRECT,
it's selected; otherwise, if exactly one widget returns
GIMP_HIT_INDIRECT, it's selected; otherwise, there is no hover
widget.
The focus widget is set when clicking on a widget (or
programatically, using gimp_tool_widget_set_focus()).
Additionally, the group can raise the clicked widget to the top of
the stack (see gimp_tool_widget_group_set_auto_raise().)
(cherry picked from commit 4ef06b9922)
... which emits the "changed" signal, for use in subclasses to
notify the tool about widget changes not resulting from property
changes.
(cherry picked from commit 614cdcc0a8)
... which takes the same arguments as GimpToolWidget::hover(), and
performs a hit-test, returning one of the following values:
- GIMP_HIT_DIRECT: The point corresponds to one of the widget's
elements directly.
- GIMP_HIT_INDIRECT: The point does not correspond to one of the
widget's elements directly, but the widget otherwise responds
to press events at this point.
- GIMP_HIT_NONE: The widget does not respond to press events at
this point.
Unlike hover(), hit() should not have any side effects.
(cherry picked from commit 385203f4d6)
... by having them disable item highlights, and any other proximity
indication, when the cursor leaves the widget.
(cherry picked from commit 5e736c697f)
... which should be called on a widget when the cursor leaves the
widget, i.e., when it stops receiving hover events.
Have the default implementation clear the tool status.
(cherry picked from commit be7eff980e)
The next few commits are going to add support for using multiple
tool widgets simultaneously. As a first step, add a notion of a
focused tool widget, by adding gimp_tool_widget_{set,get}_focus(),
which tools/subclasses can use to control focus, and a
corresponding "focus-changed" signal, which tools/subclasses can
use to respond to focus changes.
(cherry picked from commit eeed9c413b)
When Control-Button2-Zooming, remember the start point, pass it to
gimp_display_shell_scale_drag() and force gimp_display_shell_scale()
to zoom around that point by passing GIMP_ZOOM_FOCUS_POINTER and
faking the point using gimp_display_shell_push_zoom_focus_pointer_pos().
(cherry picked from commit 792cd581a2)
and remove all clipping hacks for drawing the canvas background, turns
out they never worked and we were relying on the pattern set on the
window, gah! This optimizes away one entire step of drawing of image
size, for each expose...
... _even at low zoom levels_
Pass GIMP_ZOOM_FOCUS_POINTER to gimp_display_shell_scale() when
wheel-scrolling, and change the scaling code to really honor
GIMP_ZOOM_FOCUS_POINTER and not apply magic image centering.
This keep the same point centered under the mouse for wheel-scrolling
and the zoom tool (== when the zooming is really triggered at a
certain mouse position).
GimpDeviceInfo is the only way to store per-device settings like
color, brush etc. It used to be derived from GimpContext and therefore
limited to the context's properties, causing everything else (all
tool-individual options) to be lost on device change.
Derive it from GimpToolPreset instead, so it's capable of storing
arbitrary tool options.
Adapt things to the new class hierarchy and add a bunch of signal
handlers that make sure the active device's GimpDeviceInfo is updated
properly when the tool changes. Also change device switching
accordingly.
Change GimpDeviceStatus to only show the stuff that is relevant to
each device's tool.
And various small changes to make things work properly...
Commit b279c2d217 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.
Invert zoom adjustment using the mouse or the keyboard when in
inverse mode. Take zoom factor into account when panning using the
keyboard. Fix motion cancelation.
