On generating our PDB files, we were
getting warnings about uninitialized strings.
This is because descriptions and authors
had been left off three .pdb files. Adding
these in resolved the warnings.
A new PDB author entry was also added
for Idriss Fekir.
These function names look like they should be applied to a
GimpPaletteEntry, which is a type which doesn't exist in libgimp. This
naming is much more appropriate.
They are now replaced by the more generic gimp_palette_[gs]et_colormap(),
hence making less of a particular concept of "image colormap". It's just
a palette attached to the image (and restricted to the image format).
In particular, palette's colors will want to be shown in their own space
(which may in fact be the image's space, for indexed image's colormap;
or in various spaces for named palettes).
Also make sure gimp_data_copy() also copies the proper palette format
restriction and apply it when necessary (e.g. setting the stored
colormap which is done when popping an image undo).
Otherwise we were losing format/space information, which was corrupting
color space when undoing then redoing.
If execinfo.h was not found, do not try to compile gimpbacktrace-linux.c
because the backtrace() API is not optional there.
Also I'm further improving the meson summary, regarding "Dashboard
Backtraces". Rather than just yes/no to say if the traces are detailed,
let's go for finer-grained state, saying if the traces are completely
deactivated ("no", e.g. when execinfo.h is not found), or "rough" (when
libunwind and libbacktrace are not found) or "partially detailed" (one
of these is not found) and finally "detailed".
Also add info on missing dependency between parentheses to help
packagers find the proper dependencies to get to the "detailed" state.
GBytes are a bit annoying to handle, so I'm renaming the PDB procedure
to a private _gimp_palette_get_bytes() instead, and making a wrapper
function which returns a C array and both the number of colors or number
of bytes. The latter is needed for introspection (otherwise the binding
can't know the size of the C array), but for the C API, both these
returned integers can be considered redundant (since one can be computed
from the oher), so only one at a time is mandatory.
When we want to set a full palette based on an existing one, no need to
request the full colormap from core to libgimp then back. Just set the
palette which is nothing more than an empty shell around a resource ID.
I had this case with the palette of an indexed image which had its own
reference to the image. So the image would never be freed until the
palette is freed, while the palette is freed in GimpImage's dispose()
code.
Make this a weak reference from GimpData instead.
This is not necessarily a core bug, so I can't put this message as a
WARNING or CRITICAL. It may just be a plug-in which left some image
over. Nevertheless it is still useful information for plug-in
developers, same as it can also help core developers to discover actual
core bugs (see next commit).
I had the case when gimp_exit_idle_cleanup_stray_images() would clean up
some images on exit, apparently after the GtkApplication is itself
already gone.
We have a bunch of special-casing format passing through the PDB, but
either we were only passing the encoding, or else we were reconstructing
the full format through private intermediate functions. In the
space-invasion world, this is not right. Let's have a proper "format"
type for PDB which does all the relevant data-passing for us, once and
for all!
Note that I am creating a wrapper boxed type GimpBablFormat whose only
goal is to have recognizable GValue since Babl types don't have GType-s.
Moreover I'm not using the GeglParamSpecFormat either, because it just
uses pointers which again are a bit annoying in our various PDB code.
Having a simple boxed arg is better.
gimp_drawable_filter_apply () uses the current
selection as a boundary to draw/redraw a
filter. When editing a filter, if there's an
active selection created after the filter is
added, it interferes with the filter's redraw.
This patch adds a new gimp_drawable_filter_apply_with_mask ()
function, which can be called if we want
to use the existing filter's boundaries to
draw the new filter.
Issue #3471 Unexpected results from luma darken only blend mode
Having the blend mode be perceptual results in the unexpected
result that a color with a lower actual XYZ "Y" value - that's
also clearly visibly darker than the underlying layer - can be
considered as "lighter" than a color with a higher "Y" value.
Reviewer's (Jehan) note: this only changes the default's blend space,
but in fact, we should probably even make the blend space immutable for
these 2 layer modes because the algorithm doesn't make sense in
perceptual (see #3471). We are not doing this right now in order to
not break existing XCF files using these modes in perceptual. We'll have
to figure out later how to have an immutable blend space going forward
while allowing the broken blend space but only for existing XCF images.
This should also fix the build on Windows wich fails with:
> ../app/app.c:537:7: error: call to undeclared function 'gimp_signal_private'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
Right now, running GIMP non-interactively (i.e. either as gimp-console
or with --no-interface) without --quit, the process was still exiting
immediately, yet not properly cleaning after itself. This is a
regression, since there used to be use cases with people wanting
long-running GIMP (for instance with a long-running plug-in waiting for
input through whatever inter-process communication method).
With this commit:
* GIMP now continues running when run non-interactively without --quit;
* It will catch SIGINT (typically Ctrl-C) and will quit cleanly when the
signal happens.
* At the end of the normal process (processing command line options,
such as opening images or running batch commands) and before going
on-hold, it will display some info text saying that the process can be
exited with SIGINT and informing that --quit exists if you were in
fact intending to quit immediately after the normal process actions.
* This also fixes the "gimp_finalize: list of contexts not empty upon
exit" WARNING we had when it was exiting without --quit (because of no
proper cleanup).
Note that I add some CLI text which ideally should be localized. But
since we are in string freeze, I am letting them untranslated with a
TODO (also assuming CLI-using people have more chances being used to
English, which may be or not a wrong assumption; but anyway most people
don't read the terminal output, and people running GIMP
non-interactively are even less).
Since this was not just an enhancement but also really a regression fix,
I prefer to do this now despite the string freeze and lack of
localization.
Resolves#12034
Previously, we used the Filter Tool's drawable when updating an
existing filter. However, if the user has a different layer selected than
what the edited filter is attached to, the edited filter is always put at
the top of the filter stack.
This patch retrieves the drawable from the existing filter itself, rather
than assuming the filter tool's drawable is the same one.
GimpRGB replaced with gdouble arrays.
Note that some temporary intermediate
GimpRGBs objects were added, which will
be removed when map-object and
gimpoperationgradient are fully converted
in a separate commit.
When converting an image TRC (or a precision+TRC change), we used to
convert the profile to a linear (resp. sRGB TRC) variant or use the
builtin profile, which we'd set on the image.
Pippin is telling me that "it used to be that linear and non-linear
precision gave different results, rather than only about how things were
stored". Yet this is not needed anymore. Nowadays "RGBA foo" + any
profile is linear anyway, disregarding the profile's TRC.
Furthermore, this way, we don't lose the original TRC in a non-linear ->
linear -> non-linear roundtrip and we simplify the code, which fixes
such problems as shown in #3495 as a side effect.
We check the width of the zoom label (if it exists) and use it to size the
combobox's entry field. Otherwise, we default to the existing formula.
Also removes Windows special-casing for PERCENT_SPACING constant,
as Pango now uses harfbuzz on Windows as well.
This patch temporarily reverts 02546da7,
due to performance issues with our use
of Babl. After 3.0, we'll try to improve
these operations so they can be more
color correct.
However, GimpRGB, GimpHSV, and GimpHSL are
replaced with double arrays.
There are certain operations where we're
not yet getting sufficient performance with
Babl. For these legacy operations, we'll
use the original GimpHSV/HSL conversions
internally. This will allow us to replace
them in the future without plug-in
developers relying on them.
The name for internal data may be localized. This is the case at least
for some dynamic gradients (Foreground to Background and others).
Nevertheless they have unique collection name. So let's simply rely on
this for internal data.
See point 2 in: https://gitlab.gnome.org/GNOME/gimp/-/merge_requests/1830#note_2218014
I also change the standard alias fonts to also have unique collection
names. These seem to be the only other internal data which had no unique
collection until now, which is now fixed.
gimp_brushes_popup() was triggering a popup allowing to change not only
the brush, but also the "paint mode", the opacity and the spacing. As
far as I could see, this was used nowhere for the paint mode and
opacity.
As for the spacing, it looks like gfig was indeed getting this data,
except that the GimpBrushSelect was disabling the effect on this scale
by setting change_brush_spacing to FALSE when calling
gimp_brush_factory_view_new(), and even setting this to TRUE, it was not
working fine anyway. Rather than debugging this, let's simplify the API.
Such settings seems like additional paint settings which don't have to
be in the brush selection. If someone wants people to also select an
opacity, spacing or paint mode, it would be much more efficient to add
separate plug-in arguments for these.
Additionally, I fix GimpBrushFactoryView not to show the spacing scale
when change_brush_spacing was set to FALSE anyway. This is just a bogus
widget then, which can only confuse people.
Also fixes the passing of the resource param definitions through PDB.
There was some weird assumption, with a comment, in commit 73733335c8
that this was unneeded, which meant that we were not able to properly
recreate the right param spec over the wire.
GimpOperationHueSaturation did not do
conversions since the source was already
HSL, so its GimpHSL object was replaced
with a float array.
Van-Gogh plug-in's RGB -> HSL
conversion was replaced with an
HSL float Babl format with gegl_buffer_sample ().
This abstract spec type is basically a GParamSpecObject with a default
value. It will be used by various object spec with default values, such
as GimpParamSpecColor, GimpParamSpecUnit and all GimpParamSpecResource
subtypes. Also it has a duplicate() class method so that every spec type
can implement the proper way to duplicate itself.
This fixes the fact that in gimp_config_param_spec_duplicate(), all
unknown object spec types (because they are implemented in libgimp,
which is invisible to libgimpconfig) are just copied as
GParamSpecObject, hence losing default values and other parameters.
As a second enhancement, it also makes it easier to detect the object
spec types for which we have default value support in
gimp_config_reset_properties().
As a side fix, gimp_param_spec_color() now just always duplicates the
passed default color, making it hence much easier to avoid bugs when
reusing a GeglColor.
Now you can declare a default value when declaring resource arguments to
a PDB procedure.
Add default behavior to GimpParamSpecResource.
Add field and override g_param_spec_value_set_default.
Fix the plugins that have resource arguments.
Some plugins temporarily use a hardcoded default instead of declared default.
ScriptFu plugins, TODO.
Misc fix to the test plugin for this case: test-dialog.py.
Dev>Demo>Test dialog...
TODO 10822 Lava plugin issue depends on this.
Note film.c fixed but still doesn't work.
This is a regression brought with commits 9b5463b5c5 and f7aaba9fc9.
Technically the bug already existed, but it was brought to light after
the reordering of our param bit flags, because GEGL_PARAM_PAD_INPUT
(which is set on all op properties) and GIMP_PARAM_DONT_SERIALIZE are
now the same value. It used to be same as GIMP_CONFIG_PARAM_AGGREGATE,
which, by chance only, didn't have unfortunate consequence on
serialization, yet that was also a bug. The real fix is that we should
not propagate GEGL bit flags in our operation config types.
Resolves#11993
In !1319, we added the ability to merge down filters destructively
in the Filter Tool GUI. This accidentally allowed you to merge down
a filter on a layer group. This patch adds checks to prevent this
option from being used, in the same way we hide the option when
editing an existing layer effect.
The colors are assumed to be sRGB since they come from a
pre-defined array and are used for the item color tags in the
GUI. This replaces the call to gimp_rgb_composite () with the
direct implementation of the GIMP_RGB_COMPOSITE_NORMAL
code.
It also ensures that only one call is made to gegl_color_set_rgba (),
rather than two if the color is inherited.
We weren't updating the precision of layer effect masks when
converting the layer's precision. This patch updated with the
format from gimp_image_get_mask_format ().
Note that in the future, this code should be moved to
gimp_drawable_real_convert_type () once that function is used
in all the child classes of GimpDrawable.
gimp_file_save () is used to save both XCF
and export formats like PNG. XCF does
not have a GimpExportOption parameter,
but we were unconditionally copying it.
This patch adds a check for this.
As noted by bootchk, docs of gtk_application_is_inhibited() says:
> Determines if any of the actions specified in flags are currently inhibited (possibly by another application).
The last part, between parentheses imply that it's possible for another
application to inhibit GIMP. So we should not rely on this function to
verify we inhibited the logout. Just check of we have an inhibition
cookie.
… more robust.
GIMP_PARAM_NO_VALIDATE and GIMP_CONFIG_PARAM_DONT_COMPARE were the same
value, most likely because when GIMP_CONFIG_PARAM_DONT_COMPARE got added
(commit c5c807d191), the comment to keep in sync
libgimpbase/gimpparamspecs.h and libgimpconfig/gimpconfig-params.h was
missed.
Instead, since libgimpconfig can include libgimpbase, do the other way
around: first non-GLib param flags are in libgimpbase, then we add a
GIMP_PARAM_FLAG_SHIFT, then we increment from it in libgimpconfig, and
finally we increment from GIMP_CONFIG_PARAM_FLAG_SHIFT if ever we add
more flags in app/ (right now GIMP_SYMMETRY_PARAM_GUI is apparently the
only one, but this may change).
Alx Sa