Adds a GimpCurve object and functions in libgimp.
Rather than creating a GimpCurve object in core and
passing it back and forth, we just pass the attributes
and reconstruct it across.
In the future, we may combine this with the app/core one
and put it in libgimpbase.
I think the previous code should be OK, but I had some criticals when
painting with a paint tool in the area which got extended:
> (gimp:577203): GLib-GObject-CRITICAL **: 21:37:08.402: value "-31" of type 'gint' is invalid or out of range for property 'y' of type 'gint'
It looks like there lingering pieces from the negative offset in the
buffer, which is probably a bug in GEGL?
Anyway let's go the shorter route for now, which is to copy the buffer
with a different offset. I don't think it's less efficient either
anyway.
When merging filters whose rendering was expanding in negative
ccordinates, I realized that the drawable was not properly resized (it
was resized properly when the width/height increased, but not when the x
or y points became negative, even though this "cropped" part still
showed… until you saved and reloaded your XCF!).
The problem is that drawable buffers are always stored with (0, 0)
top-left and this was just confusing our existing code. So let's check
when trying to set a buffer with a non-(0, 0) origin, and update the
offset subsequently.
I hesitated with an alternative implementation which was to edit the
buffer applied to the drawable in gimp_drawable_merge_filters(). But I
figured this would be more future-proof for other similar cases, though
I hope I did not break any use case where this was actually considered a
normal case.
This reverts commit d91a8b2abe.
As reported by Liam on #15824, this commit was clearly wrong and
reintroduced the old cropping bug with multiple filters. Reverting.
The next commit was likely good, though the real hanging bug is — as far
as my test go — in the GEGL op itself. This second commit 75e665f0ed was
improving things, but obviously, as the bug is still in the op, it can
still be triggered. We'll have to fix the source bug next.
Ah my previous commit was working fine with a selection in the "Use the
selection as input" case, but was still hanging when "Use the entire
layer as input" was chosen.
The detection of whether we were the first filter was not working fine
when adding a new filter. Now this should work in all cases.
I don't revert the previous commit, because I think it's fine anyway.
When we have a selection, unconditionally adding a cropping-before node
on the selection boundaries seems logical to me.
Hopefully it doesn't bring back any of the cropping issues we had on
filters, but so far I could not reproduce any.
Previously, we only updated an NDE filter's
`filter_area` if the filter itself contained a
width or height property.
However, the filter_area is also used by
GimpDrawableFilter to indicate where we
should draw the filter, and needs to be
updated if we scale/rotate/shear the layer
and change its dimensions.
This patch moves the code so that the
filter_area width and height is always
updated if we pass a GeglRectangle in to
gimp_drawable_filter_refresh_crop ().
This commit doesn't actually changes anything, but it fixes the
gimp_histogram_new() call, since the argument is supposed to be a
GimpTRCType, not a boolean. Yet GIMP_TRC_LINEAR is the first value in
the enum type, so it's indeed the same as FALSE.
I also set the "trc" property to "gimp:levels" config object explicitly,
to the same TRC value as the histogram, so that this doesn't depend on
the default anymore (which is linear too, right now; so this part
doesn't change a thing here again), and therefore would survive to any
possible default change in the future.
Note that it was considered to set this all to non-linear, just as it
used to be in 2.10, as requested in #15738. After discussing it with
Øyvind on IRC, we concluded that working in linear space may be a nicer
default for this feature, as we'd be doing a "meaningful rebalancing of
photon count per component". Now there may be cases where doing a
white-balancing in non-linear may yield better result, of course. For
these case, you may still go to "Levels", set to non-linear, and hit
"Auto Input Levels". This is exactly the same code runing (but in
non-linear space). The "White Balance" action still needs to be the
simple non-GUI option and keeping work in linear seems like the more
appropriate default here.
In 0157a958, we prevent the NDE crop refresh
code from running unless the filter's crop
enabled is TRUE. However, this prevents
the width and height settings built into
certain filters from running, separate from
the crop nodes in GimpDrawableFilter.
This patch moves the check to only cover
the calls to gimp_drawable_filter_set_crop ().
This should fix the width/height update issue
without causing a regression to #14442.
In 6279d7b7, I did not free the GEGL buffer created
by gimp_pickable_get_buffer_with_effects ().
This resulted in an "EEEEeEeek! 1 GeglBuffers leaked"
warning on exit, which of course could cumulate.
This patch makes to sure to clear out the src_buffer
both times it's used.
In GIMP 2.10, gimp_histogram_new () takes a boolean
parameter to indicate if it should be rendered in a linear
or non-linear TRC. In GIMP 3.0, this function instead takes
a GimpTRCType where 0 is equal to the linear enum and 1
is equal to the non-linear enum.
Since gimp_drawable_equalize () still passes FALSE as it
did in 2.10, this is treated as 0 and thus setting it as a linear
operation.
This patch changes the FALSE to be GIMP_TRC_NON_LINEAR,
both for clarify and to better match the 2.10 behavior.
When copying and pasting vector layers, if we needed
to add a new path then the layer was not redrawn.
This would require the user to move or edit the path
to see the correct view of it.
This patch adds a call to gimp_vector_layer_refresh ()
after pasting it if it is not rasterized, in order to correct
the initial view.
Color profiles were not being correctly connected to
Swatchbooker imported palettes, because the path
was included with the profile name (so a direct comparison
did not match). This patch fixes this by comparing the suffix
instead. It also fixes some minor formatting issues.
Procreate swatches are zipped JSON files.
They contain an object array of HSB
color palette values. Newer versions of the
format also support different color models,
spaces, and color profiles.
This patch adds support for importing the
palette name, colors, and associated color
profile in the original HSB format.
Resolves#15833
When we copied images in
gimp_image_duplicate_sample_points (), we only carried
over their X & Y position, not their pick mode.
This patch adds calls to get the original pick mode and
to set it to the new sample point created in the copied
image.
If a filter is inactive/invisible, it does not
affect the appearance of the drawable.
Therefore, when merging all active filters,
those filters should not be removed.
This patch adds conditional checks for
gimp_filter_get_active () and does not
remove filters on merge if it returns
FALSE. It also adds sensitivity checks in
the GUI so that the merge down button is
not active if there are no visible filters.
Property "linear" was replaced by "trc" in commit e09e563a70.
Unfortunately "linear" still stayed "as compat if needed for file
pasring" (cf. commit message) but this made a big mess, because when
setting operation properties at once, these 2 property can mess with
each other.
These migration rules are a first step in cleaning up the mess. Now we
should not have any config file with (linear) property in there,
therefore we can cleanly neutralize this property in further commits.
This was happening when trying to load a file before fonts were fully
loaded, which may happen when loading while starting GIMP (either from
CLI, or from a file browser, etc.), or simply just after start for
people with a lot of fonts, whose font loading may take a long time as
background task.
Note that I didn't manage to reproduce properly because from reports, it
seems like the problem appears where some fonts may be only partly
loaded so gimp_font_get_hash() fails to load the font and get a hash. I
never managed to trigger such a case and no reporters answered my call
for testing of debug builds.
As a consequence, I'll just assume that simply waiting for all fonts to
be loaded before starting to load images would work out.
Note that the crash was not happening when text layers were using the
older syntax (pre-XCF 19) of text layer data, since it was not storing
any font hash, which means that we were not trying to compare hashes. It
would also not crash if fonts were not fully loaded yet, but we didn't
have any weird intermediate state where fonts appeared in the list yet
their file were not hashable (cf. what I failed to reproduce, as
explained in previous paragraph). But both these cases were not ideal
either anyway because then we could load the XCF apparently OK… except
that the correct fonts would not be associated to the related text
layers (hence as soon as you start to edit said texts, the rendering
would break). So we should wait for fonts to be loaded, and that was a
bug even when you can't reproduce the crash.
When starting GIMP without loading an image, or simply when fonts are
loaded quickly enough, it won't make any difference. So it should not
make startup any slower for most common use cases and installations.
… input devices.
Per Carlos' advice on gtk#7534, I wait for us to get a focus, since the
pad devices are only created at that point.
Note that this is a Wayland-only issue, but since it doesn't matter too
much that input devices are not initialized before we have a focused GUI
anyway, let's make this simpler.
At the earliest, the splash focus can announce a focus, but since it is
possible to start GIMP without the splash, display shells will also
possibly announce the first focus (there will always be a display shell
focusing at some point for any GUI GIMP!).
This was happening in multiple cases, such as undoing a "Rasterize
filters" action, but also with a "Layer to Image Size" being undone, and
probably any other undo cases.
In particular here the culprit was that upon undoing, we were setting
the GimpApplicator's "gimp:compose-crop" node, while it was a "gegl:nop"
before. We must be careful not to set a crop unexpectedly when the node
was not set already, explicitly.
When a drawable is converted, we check if
it has filters. If any filter has a mask, we convert it
to use the new image instead of the old one.
This prevents several crashes where the filter's mask
still pointed to the old image if it was copy/pasted
into a new one.
Resolves#5627
The current limit for Clipboard Brush and
Pattern maximum size is set to 1024 because
that is the largest value that a 32-bit
architecture can safely handle.
64-bit architectures can support larger
dimensions, as confirmed by
Stanislav Grinkov during testing. This patch
therefore uses macros to increase the
size limit if we detect a 64-bit architecture,
and otherwise default to the 32-bit limit.
MR glib!4901, backported as glib!4912, will be available in version
2.86.3. Let's keep the workaround so that link layers work without
having to bump the minimum requirement, but add a GLIB_CHECK_VERSION
test. This way, it will be clear that we have to get rid of this part of
the code even if we bump the GLib requirements years ago, when we'll
have completely forgotten about this issue.
Also fix a bit of "Since:" annotations, some minor spacing fixing and
remove one useless test (if we test if a type is an item, we don't need
to test the children drawable type).
This patch adds a GimpItemChooser widget
for use in GimpProcedureDialog Item parameter
GUI creation.
This will deprecate the existing
GimpDrawableChooser, as it covers all the
same cases plus others such as GimpPath.
In 85d381bd, we fixed pass through layer groups to match
the size of the group render, allowing for filter effects to
be applied on all layers below.
This patch extends that fix to layer masks created on pass
through layer groups. This allows you to create a mask and
then selectively hide/show effects on the layer below,
like a maskable adjustment layer.
Previously, changing the color via the GimpFillEditor color button
immediately pushed each intermediate value into the color history,
polluting it with transient previews. Only the final choice
confirmed by the user should be recorded.
Now the color is recorded in the history only when the user explicitly
confirms the selection (e.g. OK/Apply), preventing noisy
history entries while preserving the expected behavior when a color
is accepted.
core: add spaces to fix alignment
As of GLib 2.86.1-1, GFileMonitors created with the
G_FILE_MONITOR_WATCH_HARD_LINKS
flag are not monitored on Windows.
This means that link layers will not
automatically update when the external
source is edited.
We will temporarily use the
G_FILE_MONITOR_NONE flag on Windows
until this is resolved
Per review, let's avoid having all the tools history in every
GimpContext.
Also a further commit will work on special-casing filter tools, which is
why we are storing up to 3 tool infos, instead of only 2.
New action "Last Tool" ("context-tools-swap"), defaulted to <shift>X.
Thanks to Damien de Lemeny for the original patch and Alexander Hämmerle
for the test case in test-ui.c.
This reverts commit 7b023177a8 and reimplement it as a CRITICAL because
if this happens, a bug has occured. If so, we don't want to hide the
bug, we want to be warned of it so that we can investigate further.
Clearly it should simply not be possible to create a parasite with a
NULL name. First if we look at xcf_load_parasite(), we were already
returning early when the name was NULL. Also even the constructor
gimp_parasite_new() has an early check and will return NULL on a NULL or
empty name.
So the question is: how come we had a parasite with NULL name (if that
is really the problem)? I don't have the answer to this and it's
possible that this bug had already been fixed somehow. But in any case,
if it happens again, we'll want this CRITICAL to run.
Sometimes, probably due to a metadata corruption, a pasarite with a NULL
name can be present in the parasite list. This causes a crash when
trying to remove it, because `gimp_parasite_list_find` does not accept NULL
keys. This commit adds a check for NULL names in `gimp_parasite_list_remove`.
This one was happening very rarely, which made it hard to track, though
I think it would happen more frequently to people with a lot of fonts
(and therefore font loading would take a lot of time) since the
problematic situation occured when the thread callback
gimp_font_factory_load_async_callback() would run after the
corresponding tagged container was created in constructor
gimp_data_factory_view_constructor().
When this happened, the source and filtered containers were not
synchronized regarding their freeze count. And in particular, the
filtered container would have one less freeze and would try to thaw once
the thread callback ran and thaw the source container, which was
provoking the CRITICAL.
