Rename gimp_tool_widget_snap_offsets() to set_snap_offsets(),
and add gimp_tool_widget_get_snap_offsets().
Also rename gimp_tool_widget_status() to set_status(), and
add new function and signal set_status_coords().
When toggling visibility of a child in an item group, we should also
toggle the visibility of other items in the same group, as well as
top-level items. Otherwise toggling exclusive visibility of any item in
a group is identical to toggling the parent's exclusive visibility,
which is simply absurd.
We still don't touch visibility of items in other groups.
The GimpLayer implementation of the GimpItem transform functions,
and the GimpDrawable convert_type() function, apply their operation
to both the layer and its mask. The subclasses of GimpLayer --
GimpGroupLayer and GimpTextLayer -- override some of these
functions, providing their own logic for the layer part, and
duplicating the mask part.
Avoid this duplication by adding a set of virtual transform and
type-conversion functions to GimpLayer. Have the GimpLayer
implementaion of the corresponding GimpItem and GimpDrawable
functions use these functions to apply the operation to the layer,
while taking care of the mask themselves. Have GimpLayer's
subclasses override the new virtual functions, instead of the
GimpItem and GimpDrawable ones.
Note that the existing implementation of convert_type() in
GimpTextLayer neglected to convert the mask, hence text layer masks
retained their old format after conversion. This issue is fixed as
a side effect of this commit.
The identity parameter checks added to the raster brush
transformation functions in the previous commit are unnecessary,
since we're already testing for the identity matrix. Remove them.
Check if the brush parameters match the identity parameters, and
return the original brush mask/pixmap if they do, in the actual
mask/pixmap transformation virtual functions, instead of in their
wrappers. While the identity parameters for raster brushes are
always scale=1, aspect-ratio=0, angle=0, and hardness=1, for
generated brushes they depend on the specific brush
parameterization.
... when clipping, if they have an alpha channel
Right now, this case is only reachable through PDB, but it will become
relevant for the flip tool soon.
by encoding them directly in the string attached to all filter
actions. The code now supports both "gegl:some-operation" and
"gegl:some-operation\n<serialized config>".
Add "default_settings" to GimpGeglProcedure to store the settings of
the invoking action, much like the "default_run_mode" member.
Change filters-commands.c to parse the new operation string, create
GimpGeglProcedures with the deserialized settings, and use those
settings when the procedures are ran.
Change the filter history to be smarter about what is already in the
history, there can now be several different procedures with the same
name.
Remove the dilate and erode actions from the drawable group, and add
them to filters, they are just special cases of value-propagate with
fixed settings.
Commit 1e6acbd4e1 modified the
generated enum recipes to run gimp-mkenums from the source
directory, instead of the build directory, so that only the
basenames of the corresponding header files would appear in
the comment at the top of the generated files. This was a
mistake -- $(GIMP_MKENUMS) is expecting to be invoked from the
build directory.
Switch back to running gimp-mkenums from the build directory. To
avoid including the relative path from the build directory to the
source directory in the generated file, add a @basename@ production
variable to gimp-mkenums, which exapnds to the basename of the
input file, and use it instead of @filename@ in the recipes for the
generated enum files.
When regenerating an enum file, don't copy it back to the source
directory if it hasn't actually changed. This allows using a read-
only source directory where the enum header is newer than the
generated file, as long as they're not really out of sync.
OTOH, *do* touch the generated source-dir file even when unchanged,
in order to avoid re-running its recipe on the next build, however,
allow this to silently fail (which is harmless).
"layers-text-tool" action shows as "Text Tool" while "vectors-path-tool"
shows as "Path Tool". That's very confusing with tools-text and
tools-vectors respectively.
These actions are mostly about entering in edit mode with the active
layer or path. For text layers, it will enter text edition on canvas,
whereas just open the attributes edition dialog on other layers. For
consistency, layers-text-edit is renamed as well too layers-edit-text.
This also fix the side effect of commits 10099bd and 526918b where I
didn't realize that layers-text-tool was also working on non text layers
on purpose (being very badly named). Now there is a separate layers-edit
and layers-edit-text.
Thanks to Pat David for English corrections. :-)
When a layer is removed from a layer stack, and its backdrop needs
invalidating, emit the UPDATE signals for the backdrop only after
the layer has been removed from the container.
A subclass of GimpDrawableStack, for layer stacks. Invalidates the
layers' backdrop as/when necessary, according to the value of their
excludes_backdrop property.
Make gimp_drawable_stack_update() protected, instead of private, so
that we can use it in GimpLayerStack.
A boolean flag, specifying whether the backdrop is clipped to the
layer. That's the case when the layer's composite mode is dst-atop
or src-in.
This is a read-only property, derived from the other attributes of
the layer. We compute its value through a virtual function, so that
GimpGroupLayer will eventually be able to specialize it for pass-
through groups.
The next commit uses this property to actually do something useful.
Add the additional enum values to enum GimpSelectCriterion, and
the few needed lines to gimppickable-contiguous-region.c.
It's horribly slow, but works.
We check them into git, so this makes it easier to keep them in
sync when using a separate build directory.
Case in point -- this commit also syncs a few enum files that went
out-of-sync with their headers.
and use them for the new image in "Paste as new image". We were using
the resolution and unit of the image the paste command was invoked
from, which is entirely random and useless.
Add a "mask-only" property to GimpBrushClipboard. When TRUE, only
create a brush mask (not a pixmap brush with mask and image).
Keep two clipboard brushes around: one classic "Clipboard Image" one
to be used as "stamp", and one new "Clipboard Mask" one that turns the
clipboard into a brush mask.
Fix brush shrinking used to compensate for the blur: avoid over-
shrinking the brush and changing its aspect ratio.
Change the way hardness maps to blur radius: hardness == 0 maps to
the largest radius such that, when the kernel is applied to the
middle pixel of the brush, the kernel is completely within the brush
bounds, taking brush shrinking into account, *assuming the brush is
a circle*.
Use the dimensions of the unrotated brush when calculating the blur
radius, so that rotation doesn't affect the blur amount (the blur
itself is not isotropic, though, and is applied after rotation, so
while the blur amount remains uniform, its effect does depend on the
brush angle.)
Get rid of the blur-radius upper limit -- it's fast enough to handle
large radii now.
A few additional minor speedups.
Also, make sure we don't overflow for large blur radii. Not a
problem yet, since the blur radius is capped, but soon...
Add a specialized convolution algorithm for the hardness blur. It
uses the same kernel as before, but performs the convolution in
(amortized) O(1)-per-pixel time, instead of O(n^2), where n is the
size of the kernel (or the blur radius).
Note that the new code performs the convolution in the input color
space, instead of always using a linear space. Since our brush
pixmaps (but the not masks) are currently perceptual, the result is
a bit different.
Both in the GimpImage API and in the GUI. The toggle in the save
dialog now controls ZLIB compression directly. Changed the various
info labels accordingly. Ditch the XCF parasite that saved the XCF
compat mode.
Enable 64 bit file offsets in XCF files, starting with newly added XCF
version 11.
We use at least version 11 if:
- we would use the previous version 10 (essentially skipping 10)
- the in-memory size of the image is larger than 4 Gig
It was agreed that we should write "plug-in" consistently. Only possibly
user-visible strings were updated.
Thanks to scootergrisen for a first patch which could not make it
after changing decision on the canonical writing.
Use gimp_item_translate() instead of gimp_item_set_offset() to set
a pasted item's position, so that the offsets of pasted layer group
children are updated correctly. Otherwise, only the group itself
moves, while its children remain positioned relative to the top-left
corner of the image.
... since that's the color space it actually works in.
Keep the legacy "Color (HSV)" mode's name as is, wrong as it is,
since, well, that's what it used to be called...
When adding an item to a filter stack that doesn't have a graph yet,
calling gimp_filter_stack_update_last_node() may ultimately lead to
the invocation of gimp_filter_stack_get_graph(), which would create
a new graph, and add the item's node to it; gimp_filter_stack_add()
would then erroneously attempt to re-add the node to the graph.
Fix this by calling gimp_filter_stack_update_last_node() after
(potentially) adding the node to the graph in
gimp_filter_stack_add().
