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.
Since libgimpui also use GIMP_ as prefix in C, we won't ever have name
clashing with libgimp, so I also remove this prefix in Script-Fu.
E.g. GIMP_ASPECT_SQUARE is ASPECT-SQUARE in Script-Fu.
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.
It is possible for qbist_info.path to be NULL, which
makes gtk_file_chooser_set_filename () throw a warning
about a NULL filename in save_dialog ().
This patch adds the same guard to that call as QBist
already has in load_dialog (), to make sure we have
an existing file name before trying to set it.
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.
From https://gimp.org/bugs/report.html:
> Related to bug reports are enhancement requests. It is recommended to discuss enhancements with developers first, for instance on IRC or in the forums. This is to make sure that the enhancement requests that are filed are well-specified and aligned with the overall goals the developers have for GIMP.
See: d2c4038abd
Our practice of writing everything on the template made the page on gimp-web
fall into oblivion. This was suboptiomal since the template got very big and
hard to read, with many reporters not filling it at all.
So, let's try to improve cleaning the template and directing them to gimp-web,
which have images and such that should clarify how to make good reports.
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 fixes Spyro Plus not running interactively after commit a7f02d4ee1.
Note that this seems to be the only plug-in which got broken by this
commit AFAICS.
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.
The create guides dialog of the imagemap plug-in shows up very wide
due to the hint text not being wrapped.
To fix this we enclose the hint box inside a scrolled window and set
horizontal policy to GTK_POLICY_EXTERNAL and a minimum vertical size
of 100, based on how we do this in the export procedure dialog for
the comment field.
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.
Our export dialog resizes the width of the dialog based on the size
of the longest comment line. Apparently certain programs save data
that can be very long. On Windows I did not experience a crash, but
the dialog is many screens wide and unusable in that state.
To fix this we change the horizontal scroll policy to
GTK_POLICY_EXTERNAL because GTK_POLICY_NEVER apparently stops GTK
from resizing the window at a reasonable size.
We also set wrap mode of the comment field to GTK_WRAP_WORD_CHAR
to make sure the lines that consist of only numbers without spaces
get wrapped at a reasonable length.
When we switched the NDE popover to use
GimpRow instead of GtkTreeView, it inherited
the `list row` style which is inverted in comparison.
This resulted in the "selected" filter looking like an
unselected row and vice versa.
This patch adds a more specific version of the theme
to GimpRow when it exists in the NDE popover widget,
to prevent this confusion.
