I'm moving the logic of choosing a correct default for width/height by adding an
"extract dimensions" callback in the procedure. The logic is that every vector
format out there should likely have metadata either for pixel dimensions or
physical dimensions, or at the very least for no-unit dimensions (ratio only).
Vector load procedures will have to implement only the extraction of such data
in a callback called by GIMP but not how to act upon them, so that we have a
common logic for all vector images.
I am implementing this callback first in the SVG plug-in, moving all the code
to extract dimensions (and improving it) in this callback.
Also I am deleting "file-svg-load-thumb" procedure. I could simply reimplement
it using the same code, but it looks to me like this is very useless for vector
formats to have a specific thumbnail procedure (unless it were to use very
specific metadata for faster result). This is vector data, just ask it directly
at the proper bounding box size.
Resolves#11568
Currently, the Stroke/Fill Paths options on
the Path tool disregard the Pixel Locked
flag for layers. This patch resolves this as
follows:
* On the Paths tool, the Stroke/Fill button
does not pull up a dialogue if a single
layer is selected and it's pixel locked.
* If multiple layers are selected, only those
that are not pixel-locked have the Fill/Stroke
applied to them.
In both cases, a warning is also displayed.
For now, we can't keep certain GEGL ops
like Gradient as NDE filters, since they are
connected to tools. If the layer is copied
or saved as an .XCF while the tool is still
active, it attempts to save it and causes a
crash.
This patch adds a check to make sure the
copied filter has been commited and that
it's not a tool-based NDE filter before
being copied. It also adds some NULL
checks where gimp_drawable_filter_duplicate
is used to prevent NULL from being
added to the filter stack.
Resolves#10765
This allows us to retain any filters that a
layer group's children might have when
copied or exported. They were previously
lost when the group layer was duplicated.
Note that an OR condition was added to
GimpDrawableFilter creation, to allow
one to be created if the layer was
attached to a parent layer rather than the
image.
Resolves#11404
Since the GimpContainer selected function automatically updates which filter is the
"active" selected filter, we can remove the code that sets it to NULL after a filter
is deleted. This fixes a bug where the top effect was always deleted in subsequent
attempts rather than the highlighted one.
A now unnecessary gimp_drawable_remove_last_filter () function was also removed.
Should resolve#11392
In dfb26f37, the NDE filters in the copied image are
retrieved with gimp_image_get_layer_iter (). This works
fine for single layer images or when all the layers are copied
at once. However, if a subset is copied then the filters are always
copied starting from the top level of the image. This can result
in an incorrect filter being copied to the wrong layer.
To fix this, we get the filters from the provided drawables list
instead. This matches the number of layers in the copied
image exactly, since it was used to create the copied image.
This happens in particular for in-build runs (or when using
GIMP3_DIRECTORY environment variable on an empty directory). In any
case, I don't see why we wouldn't try and create a directory which was
configured for data storage.
Per Pippin, the only color model that can
have double precision is RGB/A.
Therefore, we need to switch all others to
use float instead. This patch converts the
HSV and HSVA double babl formats.
New functions with the same name as these functions are created, except without
the length argument (i.e. it's equivalent to calling these with -1).
The reason for this is that using strings with a length variant which may be
negative to switch to NUL-terminated strings are not bindable. At least in our
case, when testing in Python, the input string ended up as corrupted garbage and
GObject Introspection docs warns about such interfaces:
> In particular, avoid functions taking a const char * with a signed length that
> can be set to a negative value to let the function compute the string length
> in bytes. These functions are hard to bind, and require manual overrides.
(see: https://gi.readthedocs.io/en/latest/writingbindableapis.html#strings)
So instead, I create a simple version which runs on NUL-terminated strings only
and which is bound, whereas unbinding the generic length-version (making it
C-only, or maybe usable in some other bindings which ignore the (skip)
annotation; apparently some do this).
This is meant to obsolete GeglParamColor with at least an additional argument
has_alpha which we need in GIMP. It allows to advertize when a parameter wants
an opaque color, which in particular means we know when displaying a GUI to pick
colors with alpha or not.
Switch to using gimp_item_convert ()
instead of gimp_item_duplicate () so that
the filter mask can be properly associated
with a new image when copy/pasted.
Previously, filters were lost when copying
individual layers. This patch copies them
to the clipboard image on cut or copy,
then copies them back to the pasted
image.
It also fixes an issue where filters would
be merged down if a selection was
copied instead of the entire layer.
Previous code would only set the class member when we were actually
loading fonts, so we ended with code paths where the member was NULL.
Fixes:
> GIMP-CRITICAL: gimp_container_get_n_children: assertion 'GIMP_IS_CONTAINER (container)' failed
It should hopefully also fix#11219 (though I couldn't reproduce this
failure).
Resolves#11054
NDE Filters clip to the size of the layer when
applied. Group layers get their dimensions from
the largest layers under them, so an empty
layer has dimensions of 0 by 0. This means a
filter applied when the layer group is empty will
be clipped to 0 by 0 as well.
This patch adds code to refresh the filter's crop
whenever the group layer is resized by a
layer being added or removed.
752f0fb4 did not fix saving/loading filters
in .xcf files. To do this, a new function to
retrieve the clip setting was added to
gimpdrawablefilters.c, and then used to
save the value in xcf-save.c. The existing
set_clip function was used in xcf-load.c,
just like in 752f0fb4.
Resolves#10997
When filters are duplicated for export, the clip property was
not being copied over. This caused filters that go outside the
layer boundaries (like Drop Shadow and Long Shadow) to be
clipped incorrectly.
The simple fix was to copy over the clip value when the new
filter was duplicated.
Resolves#11147
Applying the same reordering code
in cbb1e816 to adding a floating selection.
When anchored, floating selections were also
merging down all layer effects onto the original
image. This patch places the float selection
under the layer effect when added, both to prevent
this and because it seems to be the expected
behavior based on user feedback.
When the config directory is set by an environment variable, the version is
likely not part of the directory path, and therefore strstr() would return NULL.
Fixes:
> (gimp-console-2.99:41446): GLib-CRITICAL **: 13:19:34.933: g_vsnprintf: assertion 'n == 0 || string != NULL' failed
Since commit 10b96b1025, we had buffer leaks as soon as we ran filters.
gimp_drawable_get_buffer_with_effects() was either creating a new buffer (when a
drawable had filters) or not. And calling code couldn't know which is which.
Code needs to be consistent. Either we return a new reference to take ownership
to, or not. So let's change to add a new reference to the drawable' buffers so
that it always returns a new reference to free.
Resolves#10762.
Updates gimpdrawable-preview.c to use
gimp_drawable_get_buffer_with_effects (),
which includes any NDE Filters applied to
the layer in the preview.
The preview is also set to update when a
filter is applied non-destructively.
The indexed conversion code was originally written for very low-memory systems,
this makes the mapping it does quantized and noisy, for examples see issue
#5159 this commit removes quality/memory use trade-offs, modern machines can
take a 2-300mb temporary table allocation.
We were not properly duplicating the left and right colors when duplicating the
existing segments in gradient_editor_save_selection(). Therefore we ended up
freeing original GeglColor on exiting the GimpColorDialog.
Additionally to the reported crash, I add a few GeglColor freeing which were
leaked and some safeguard in gimp_gradient_get_flat_color() to ensure it always
returns a color (or raise a CRITICAL to be investigated easily).
Finally a few signals in GimpColorDialog had to be ensured disconnected when the
dialog is destroyed.
We don't try anymore to convert early from a pickable color to another
format/space. Now we are able to get a GeglColor and move it around,
doing only last-second (when needed) conversions.
I also changed a bit the new color serialization by adding a (color …)
symbol framing the contents, for cases where we don't have a specific
property name, e.g. for the color history list stored in colorrc, unlike
for GimpConfig GeglColor properties.
While doing this, I moved GeglColor property deserialization code into
gimp_scanner_parse_color() which is now able to recognize both older
(color-rgb|rgba|hsv|hsva with no color space) and newer serialization
formats ("color", color model agnostic and space aware).
We historically have both the colormap and palette concept in core GIMP,
though they are actually kinda the same concept, except that with
"colormap" we work with an array of raw data and it's a lot less
color-aware. It is still much more efficient in some specific cases,
such as when converting the image (we can then convert the whole palette
as a single buffer, because the image palette is space-restricted
anyway), when storing undo data or when storing/loading in XCF.
But for all the rest, let's use gimp_image_get_colormap_palette() and
work with the GimpPalette API.
By default a palette can contain any mix of color models and space. These new
internal API add a concept of format/space restriction. For now this will only
be used for indexed images whose palette should only contain colors for the
specific palette format and space (at least as currently implemented in GIMP).
I still see some limitations in GimpGradient, and in particular, they are still
always stored as RGB in GGR files. It would be nice if we could store the actual
color format. This way, if someone chooses a gradient stop as Lab or CMYK color,
that's what the gradient file would keep track of. But also even storing the
space of a color (instead of storing/loading always in sRGB, even though this
may still work fine as we store unbounded double values). This might warrant for
a v2 of GGR file format.
This commit also fixes loading of SVG gradient which was apparently broken
regarding hexadecimal color parsing.
Finally I improve gegl_color_set_alpha() by adding an alpha channel when the
initial format had none.
