paint_core->start_coords is in fact the last stroke's endpoint and
only used for storing it in GimpPaintCoreUndo, so the last endpoint
can be resotred for straight-line painting after an undo. Make the
code actually doing that.
(cherry picked from commit d1795ac204)
...if layer bounds are changed.
Call gimp_tool_control_set_preserve (tool->control, FALSE) so it is
stopped when the drawable changes.
(cherry picked from commit 2e8ef97c13)
When a drawing timeout happens too close from the previous drawing, we don't want to cancel
the timeout function (FALSE), but simply retry later (TRUE).
In our case in particular, if you move your pointer very fast over a guide, the highlighting
drawing was happening less than MINIMUM_DRAW_INTERVAL before the un-highlighting drawing,
hence canceling the later, which caused the drawing bug.
(cherry picked from commit 3496e178ef)
Applying a preset overwrites all the tool option's properties, also
temporarily its name. This name change gets auto-synced with the
option's text proxy object which also inherits from GimpObject and has
a name. Make sure we don't queue that name change for being applied to
the text layer's text object, because that code only handles
properties of GimpText itself.
(cherry picked from commit 931ea102f8)
ROUND() is consistent only on positive values, and bad rounding
creates an offset when negative values are involved. Introduce
SIGNED_ROUND() and use it in gimprectangletool.c. It should probably
be used in much more places.
(cherry picked from commit 4a5a6ef914)
Check for layer groups and locked layers in gimp_selection_tool_start_edit()
and show the usual warning instead of allowing the forbidden operation.
(cherry picked from commit 593ddb741f)
when it was in the floating text style editor. While this doesn't fix
anything by itself, it enables fixing text style setting to behave
reasonably when there is no selection.
(cherry picked from commit 76b05c2afc)
Don't install the frame rate limiting draw timeout when resuming a
draw tool that is not active, so accidential timeout installation from
whatever tool dispose code can't happen.
(cherry picked from commit 6a33951aa6)
It seems that when the undo action reverts a text -> mark-up change
(or v.v.) the notifications are inverted, first is emitted the new
value notification and successively the property becoming NULL. The
result is that gimp_text_buffer_set_{text,mark-up} is called last with
NULL, unsetting both text_buffer text and mark-up.
The right way to do it is to always prefer "markup" over "text" if
markup is present, no matter if the notification was for "markup" or
"text".
(cherry picked from commit 9b58e2ba0c)
gimp_text_tool_options_notify(): always show the editor, also when no
text object exists yet. There was no reason for this limitation.
(cherry picked from commit 2b3e5ebd78)
Even less drawing: let the timeout running if it triggers within the
50ms since the last drawing, so it's reduced to its actual purpose of
updating to the actual cursor position after framerate-limiter skipped
drawing.
(cherry picked from commit 52d933a1cc)
One more try: merge the spirit of Alexia's patch, but don't disable
the timeout, only make sure the minimum fps is also applied when
drawing is triggered by gimp_draw_tool_resume().
(cherry picked from commit 4218d9342f)
Keep around the last drawing time in GimpDrawTool and make sure we
draw at least with a frame rate of around 20 fps, which feels
reasonably non-laggy.
(cherry picked from commit fd4e220c28)
Set the step/page increments to 1.0/10.0 for brush size and to 0.1/1.0
for aspect ratio. the previous values were way too small.
(cherry picked from commit 2c3a046d83)
Reset the tool on image changes again, but not if only the active
drawable changes, so keep bug #678890 closed:
Introduce new dirty flag GIMP_DIRTY_ACTIVE_DRAWABLE and set it on all
tools' dirty_mask except for rect select. Check the new flag when
reseting the active tool because of a drawable change.
(cherry picked from commit e546f2b43b)
Make sure that temporarily setting/unsetting tool->control's "preserve
tool across image changes" does not mess up the default value:
Introduce gimp_tool_control_push/pop_preserve() which restores the old
state automatically, and use it in all tools, instead of saying
set_preserve(TRUE/FALSE) around image changes.
(cherry picked from commit 078128bb09)
Check for pango_layout_move_cursor_visually() returning a new index of
G_MAXINT, which indicates that we moved beyond the end of the layout,
and do nothing instead of trying to access the memory there.
(cherry picked from commit 7d280abd9a)
Make sure to not override the logic that separates the tool option's
selection mode from the one determined by modifiers, by blindly
calling gimp_modifiers_to_channel_op(state) on a zero state.
(cherry picked from commit 2d882dd64f)
because the tool might be cancelled from some other place opening an
undo group, so flushing the image would update menus and whatnot while
that other operation is running, with unforeseeable side
effects. Also, flusing the image here is not needed because we didn't
change anything in the image. Instead, make sure manually that the
display is updated correctly after restoring GimpImageMapTool's
temporary editing.
(cherry picked from commit e7e8c9ef0a)
gimp_transform_tool_real_transform(): make sure we clip layer masks
and channels to their original extents also when transforming them
completely (not just a selection of them).
Executing Desaturate... or Posterize... used to print:
Gimp-Widgets-CRITICAL **: gimp_settings_box_add_current: assertion
`GIMP_IS_SETTINGS_BOX (box)' failed
When setting the unit of a property shared with a gimp_prop_size_entry,
a conversion is applied to the corresponding size property (to preserve
size_entry's ref-value), but the conversion risks to change the size
property already updated.
To update, at the same time, size and unit, it is better to start updating
size_entry's unit in order to trigger the useless conversion on the stale
size.
Instead, either destroy the child instead of removing it, or remove
*and* destroy it in cases where the remove() api on the "parent"
doesn't match GTK+'s parent/child relation (like with all our dock
widgets). We can't rely on remove() to implicitly detstroy, because
there might be arbitrary other code holding references, such as
accessibility modules and whatnot. Most likely fixes unclear crashes
in accessibility code and other crashes we blamed GTK+ for.
One possible way to decrease the incompatibilities
between letter spacing in a tagged gtk_text_buffer
and in an equivalent pango_layout
Remove also a valgrind reported invalid write in
gimptextbuffer.c
