… from a plug-in.
The value is accepted by the current specification of "channel" but it
is actually not supported and would end up crashing the core process.
The real fix which should happen would be to make GimpParamSpecEnum
usable in libgimp, and be able to pass its spec through the PDB. Then we
could use this param spec instead of GParamSpecEnum for such property
not supporting all values in an enum.
Note that with the current fix, the "gimp:curves" filter will silently
refuse the Luminance channel when passed as "channel". It is not ideal.
But it's better than crashing the whole of GIMP!
… gimp_drawable_curves_spline().
We can now run directly "gimp:curves" operation, both destructively or
non-destructively, but also setting the TRC, as well as individual point
types (when the curve is of type "smooth" instead of freehand).
This is much more powerful!
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.
Same patch as cb552d3d, just applied to GimpPrefsBox.
This was visible in the Preferences Dialog, where the same
unnecessary pop-up appeared in the side panel.
When we copy and paste a vector layer,
we need to reattach its path to the
(potentially) new image. Similar to what
we did for NDE filters in 8db97f4e,
we convert the existing path if necessary
before continuing with the gimp_item_convert ()
process. This prevents several CRITICALs,
for instance when copying a group that
contains vector layers rather than the
vector layers directly.
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.
This patch replaces adding a custom widget
to the Path Export dialog with a built-in
combobox from gtk_file_chooser_add_choice ().
This makes our code more compatible
with a future port to native file dialogs
in GTK3, without a loss of functionality.
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.
Resolves#11409
After Jehan's update to
gimp_drawable_filter_refresh_crop () in
0157a958, it no longer calls the cropping
functions which this commit was intended
to work around.
Additionally, thanks to other changes in
the filter code since then, reverting this
commit resolves an issue where some
Render filters would not update as you
typed more characters.
This was happening on Wayland in my tests, and apparently on Windows
too, according to the report. I widely simplified the code. Now we don't
list of axis anymore, and therefore we don't allow to change these
(which was not working anyway, for as long as I remember, at least on
Linux, both X11 and Wayland).
As for the pressure curve, we just show it unconditionally for any
device of type "Pen". It may mean that it might show on some rare stylus
devices with no pressure support, but in such case, it will just be a
bogus curve (it won't break the device).
And then we'll avoid all the flimsy heuristic trying to guess if a
device is supposed to have pressure sensitivity, which especially became
bad in Wayland as we have this information only on proximity. It means
that if you don't approach the stylus and were trying to set up your
pen's pressure curve with a mouse, no curve would appear!
Add to this that gdk_device_list_axes() seems very broken on Wayland and
was always returning GDK_NONE for all axis (even when only using it on
various device signal handlers, per advices by Carlos on IRC), at least
anyhow I tried to make it work, our heuristic to detect when an axis
should be ignored was completely broken on Wayland as well.
A simpler logic should work better and makes the code simpler to read
too.
It's also one less usage of GtkListStore, which is good for future GTK
versions where it got deprecated!
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.
Since the Text Editor window uses the same
GimpTextStyleEditor widget as the on-canvas editor,
it also shows the Move handle (which doesn't work
in the Text Editor window). This patch simply hides it
so it doesn't confuse users.
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.
The code to ban some filters for non-destructive usage was duplicated in
a PDB file and in the XCF load code. Additionally to combining these 2
codes into a single gimp_gegl_op_nde_allowed(), this commit also moves
part of the logic into gimp_gegl_op_blacklisted() which improves the
following:
* It used to be possible to create filters for hidden operations which
were not returned by gimp_drawable_filter_operation_get_available(),
such as "gegl:color" or "gimp:equalize", which would create all sorts
of problems. Now trying to create these filters through the API will
not work and will properly warn with an explicit error message.
I do not consider this an API break since the filters were not
returned in the available lists and therefore were not considered
usable. Anyone who would have used any of these hidden filters was
just going around a weakness in our implementation.
* We make sure that our lists of allowed/forbidden filters are
consistent across usages.
* When getting the list of filters with gimp_gegl_get_op_classes(), we
don't need to do an additional validation step (as we were doing until
now in the PDB call). This is meant to imply that all returned
operations were already validated.
This operation cannot be run from the public API right now because it
requires the "histogram" argument whose type is currently unknown to
libgimp/PDB.
Furthermore even if we were to add this type, there are some fundamental
issues with this op which makes it unsuitable (for now) as a
non-destructive filter:
1. Since the histogram is computed only once at op construction, it
wouldn't be rebuilt when the source buffer changes.
2. Using gimp_drawable_calculate_histogram() doesn't build from the
source buffer of the node anyway, but from the drawable buffer. This
would mean a broken histogram as soon as the filter is inserted in
the middle of other filters (anywhere but in the bottom).
We will need to fix these 2 points to consider using this as NDE (and
therefore also make it available in the API).
The trc variable could be initialized by the "trc" property, but even
though this is processed inside GimpOperationPointFilter code, the
property is only set in some of the child classes (such as Curves or
Levels). As a consequence, this was left unitialized and even actually
used in other child operations (unless they overrode prepare()). This
was the case of GimpOperationEqualize which was always working in
linear mode since GIMP 3.0 (see #14486).
Since uninitialized variables may end up as 0, which would have been
GIMP_TRC_LINEAR enum case anyway, this probably doesn't really change
the behavior. This is not guaranteed by C, but IIRC GObject zero-ed
object structs. Yet it is always better to be explicit.
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.
In the path tool, when setting a new vector layer as
the editable path, we try to disconnect the old signal for
gimp_path_tool_vector_layer_path_changed () from the
vector layer options. However, if this code is triggered
because we rasterized the vector layer while the path
tool was active, it will throw a warning because the
layer options are NULL. This patch adds a check to make
sure the options exist before trying to disconnect their
"notify::path" signal.
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.
When copying and pasting a vector layer into
another image, the display would jump back to
the original image. This also happened if you
re-selected the pasted vector layer in the new
image after choosing another layer.
This patch makes sure that when updating the
selected path in the Path tool, it grabs the display
from the pasted vector layer rather than the old
image's path.
Note that this may be a "symptom" rather than a
root cause, due to a number of remaining issues
with copying and pasting vector layers.
The Canvas Size dialogue and the default options
for it in the Preferences dialogue were listed in
opposite order. This patch puts them in the same
order as the Canvas Size dialogue (Fill with, then
Resize Layers) to keep them consistent.
This patch adds a CSS class name to
GimpPivotSelector so we can define its
CSS style in the GUI.
It also defines the margin-right CSS property
to prevent it be affected by the general
GimpOverlayDialog style.
Applies f78a0629 and b420a773 logic to
gimp_image_get_thumbnail () so it
converts higher bit-depth images to 8 bits
for GdkPixBuf.
This affects plug-ins like GFig which use
a full image preview, as well as thumbnail
metadata exports and image combobox
previews.
When we export paths in GIMP, we escape the <title>
text to ensure it matches the SVG specification.
On import, we were not unescaping the text. This resulted
in changed path names when copying and pasting within
GIMP itself.
This patch adds a call to g_uri_unescape_string () to convert
the escaped text back to its original format.
Per user request, this allows you to use
arrow keys to adjust the shear tool.
Left/right move the shear on the X axis,
up/down move the shear on the Y axis.
By default, it moves one pixel at a time.
If you hold shift (similar to the move
tool), it moves based on the slider's
page increment setting (factoring in the
current zoom).
This patch conditionally adds an alpha
channel to a layer when using the Crop
Tool, under the following conditions:
1) "Selected layers only" is checked
2) "Allow growing" is checked
3) "Fill with" is set to transparency
4) The crop rectangle is larger than the
width or height of the layer
5) The layer does not already have an
alpha channel.
Resolves#13014
In GimpHistogramEditor, pixels and counts are stored
as doubles. We previously converted them into 32bit integers
when displaying the values to the user.
As it is possible for the dimensions of an image to exceed the
limit of a 32bit integer, this could lead to overflow and negative
pixel counts.
This patch switches our display code to use 64bit gsize casts
for conversion to prevent this from happening.
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.
...on start.
Users who open GIMP with images
(such as via the command line or drag & drop)
may not want the Welcome Dialog to
appear over their image.
This patch moves the check for files to be
above the code that loads the Welcome
Dialog, so that we can pass that information
to gimp_update_auto_check ().
If files are being loaded, we don't display
the Welcome Dialog (with the exception
of on first update, so users don't miss the
update information).
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.
Per user request, this allows you to flip
on-canvas items with the arrow keys when
the Flip tool is active. Left/right arrow keys flip
horizontally, up/down arrow keys flip vertically.
Note that having an active guide highlighted overrides
this distinction - pressing any arrow key will always flip
over the guide, same as with the mouse.
