In GimpChainButton, emit the "toggled" signal whenever the chain
button's "active" property changes, either due to user interaction,
or programatically. Previously, it would only get emitted when the
button was actually clicked.
In particular, this fixes an issue where the aspect ratio of a
coordinates size-entry won't get updated when its chain button got
toggled programatically, as can happen with the scale tool.
(cherry picked from commit c0c055b4e9)
Again some missing context when requesting the strings (while they were
declared with context in static NC_()).
Also some mixup with some zoom actions strings declared with different
context in the same GimpEnumActionEntry.
(cherry picked from commit 6c5b6c6135)
Similar to master commit cb025cec64,
except that I just redid the search-replace as there were annoying
conflict merge (was easier to just redo massive search-replace).
See commit f8f3a74971.
The context change was basically a bug fix, and nothing changed in the
original string, nor its actual GUI context/usage. Therefore there is no
need to invalidate the translations (mark it "fuzzy", which would be
what would happen automatically after this change) for the 43 languages
which already translated these. Let's just search-and-replace all the po
files with the correct context.
For the record, I got the green light from several translators on
gnome-i18n ML so let's fix. :-)
(cherry picked from commit 7a5e5be35e)
The line art imaginary segments/splines are not added when they create
too small zones, unless when these are just too small ("unsignificant").
Why the original algorithm keeps such micro-zones is because there may
be such zones created when several splines or segments are leaving from
a same key point (and we don't necessarily won't to forbid this). Also
we had cases when using very spiky brushes (for the line art) would
create many zones, and such micro-zones would appear just too often
(whereas with very smooth lines, they are much rarer, if not totally
absent most of the time).
Also it is to be noted that the original paper would call these
"unsignificant" indeed, but these are definitely significant for the
artists. Therefore having to "fix" the filling afterwards (with a brush
for instance) kind of defeat the whole purpose of this tool.
I already had code which would special-case (fill) 1-pixel zones in the
end, but bigger micro zones could appear (up to 4 pixels in the current
code, but this could change). Also I don't want to use the "Remove
Holes" (gimp:flood) operation as I want to make sure I remove only
micro-holes created by the line art closure code (not micro-holes from
original line arts in particular).
This code takes care of this issue by filling the micro-holes with
imaginary line art pixels, which may later be potentially bucket filled
when water-filling the line art.
(cherry picked from commit 72092fbdbc)
Plug-ins are not prepared to handle high-precision brushes/
patterns, even when they're otherwise aware of high-precision
drawables, so make sure to always use compat formats when
communicating brush/pattern data to plug-ins.
Allowing plug-ins to handle high-precision brush/pattern data would
require some additional API.
(cherry picked from commit 82c449496e)
Older --enable-binreloc configure option had basically the same purpose
as the newer --enable-relocatable-bundle, though the old binreloc was
only used for gimpenv.c code.
As a consequence, commit 10ce702188 was still not working fine since
gimp_installation_directory_file() also need binreloc enabled (to be
actually relocatable).
Let's get rid of this whole mess, by implying we want binreloc code to
be used when --enable-relocatable-bundle is ON. We don't need the
m4macros anymore, since AM_BINRELOC was basically just checking that
`/proc/self/maps` was present. But anyway being present at compile time
does not mean it will be at runtime (nor the opposite). So this test is
not that useful. The binreloc code will anyway fallback gracefully to
the non-binreloc code (i.e. trying to use build-time install paths) if
the procfs is lacking at runtime.
(cherry picked from commit 4d84c1d7ee)
Avoid unnecessary calls to gimp_temp_buf_data_clear() in various
places, where either the entire buffer is being written to, or most
of it is, only requiring clearing the edges.
(cherry picked from commit 9d19e804ed)
Promote the precision of generated brushes to 32-bit float, and
modify brush preview generation, and gimpbrushcore-loops, to handle
float brushes. This avoids posterization in large brushes.
Note that non-generated brushes are still uint8.
(cherry picked from commit 8ef1113dee)
In GimpTempBuf, add gimp_temp_buf_lock() and gimp_temp_buf_unlock()
functions, which lock/unlock the buffer for data access. Unlike
gimp_temp_buf_get_data(), which returns a direct pointer to the
buffer's data, the new functions take a format parameter and may
return a temporary buffer, allowing the buffer to be accessed using
an arbitrary format.
(cherry picked from commit 12dde445c4)
In GimpTileBackendPlugin, avoid storing read/written tiles in the
libgimp tile-cache, since caching is already done by GEGL.
(cherry picked from commit 47dcd4b93a)
Add a GimpTransformGridTool::matrix_to_info() virtual function,
which should extract the tool-specific transformation parameters
given a transformation matrix, and the old parameter set (which is
needed in some tools, to derive the parameters that aren't encoded
in the matrix, such as the pivot point). The transformation matrix
can be any combination of matrices calculated by the tool, and
their inverses. Subclasses should only implement this function if
every such matrix can be mapped back to transformation parameters.
This is currently the case for all the transform-grid tools, except
for the shear tool (since it only supports shearing along one of
the horizontal or the vertical directions, however, the combined
matrix may require shearing in both directions).
When a transform-grid tool implements this function, show a chain-
button between the two transform-direction radio-buttons in the
tool options. When the chain-button is linked, whenever the
transform corresponding to the active direction is modified, adjust
the transform corresponding to the non-active direction such that
the overall transform remains the same.
One notable workflow that this enables is transforming a layer
while adjusting a different area than its boundary, by first
defining the area while the transform-directions are linked, and
then transforming the area while the transform-directions are
unlinked.
(cherry picked from commit 39e23267f7)
In GimpTransformGridTool, allow performing simultaneous forward
(normal) and backward (corrective) transforms, by having each
transform direction operate on an independent set of parameters.
In other words, whereas the transform-grid tools previously had a
single transform, which could be applied either normally or
correctively using the "direction" tool-option, they now have two
independent transforms, one applied normally and the other
applied correctively, which are toggled using the "direction"
option. The overall transform is the combination of the backward
transform, followed by the forward transform.
Another way to think about it, is that the tool transforms a source
shape into a destination shape. The source shape is defined by the
backward transform, and the destination shape is defined by the
forward transform. Wherewas previously only one of these shapes
could be controlled (the other shape always being the item bounds),
it's now possible to control both shapes in a single transform.
The next commit will allow modifying both shapes simultaneously,
making this even more useful.
Note that since both transforms start off as the identity, using
only one of the transform directions has the same behavior as
before.
(cherry picked from commit de8e81f81f)
... and corresponding gimp_chain_button_{get,size}_icon_size()
functions, which control the chain-button's icon size.
(cherry picked from commit 8d6c7e42bf)
Add an undo_desc field to GimpTransformToolClass, which subclasses
should set to the tool's default undo description. Provide a
default implementation for the get_undo_desc() vfunc, which returns
(a copy of) undo_desc. This simplifies transform tools that have a
static undo descrption, as well as provides a fallback when a
detailed undo description can't be generated (not currently
relevant, but will be used in the next commit).
(cherry picked from commit d549440650)
When rotating an item around its center using the rotate tool,
i.e., if the pivot point hasn't been moved, don't include the pivot
coordinates in the undo description.
(cherry picked from commit 44c8a1f274)
In GimpToolCompass, add a read-only "effective-orientation"
property, which returns the actual orientation of the compass; in
particular, if the "orientation" property is set to AUTO,
"effective-orientation" returns HORIZONTAL or VERTICAL, depending
on the current compass direction. In 3-point mode, the property
always returns AUTO.
(cherry picked from commit 40c0913178)
In GimpMeasureTool, don't try to access the "straighten" button
when halting the tool if it's NULL, which can happen when the
measure tool is selected upon startup, but is changed before its
tool-options GUI is constructed.
(cherry picked from commit 7fc5698f32)
In gimp_transform_matrix_generic(), apply the resulting matrix even
if the transformation is invalid, since GimpGenericTransformTool
relies on the matrix to properly update the transform-grid widget.
(cherry picked from commit 59ef222c7f)
In GimpTransformGridTool, when the "show-preview" tool-option
changes, don't take the transform validity into account when
deciding whether to hide the current layer -- it should only affect
the visibility of the preview, not the layer.
(cherry picked from commit 7ed512040e)
...1920*1980 resolution
In GimpOperationTool, make the generated GUI scrollable if it is
higher than half the monitor's workarea. This is meant as a last
resort for generated GUIs that do not have a custom constructor that
makes them usable using better layouts.
(cherry picked from commit b85d7c2334)
