As far as I understand, the created types are never "unregistered" and
will live in the process until it ends. It cannot even have a custom
class_finalize() (looking at g_type_register_static()'s code, a CRITICAL
is emitted if you try to provide a class_finalize() implementation).
So let's just free the allocated pspecs at the end of class_init()
instead.
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.
We didn't have a "destructive-action" class anymore and the
"suggested-action" was hidden by further CSS rule, so it needed to be
moved down so that it gets precedence.
We used to have these as red and green buttons originally (e.g. pasting
as floating selection, the "New Layer" and "Anchor" were the suggested
actions, i.e. green, whereas "Delete Layer" was destructive, red). For
GIMP 3.0, we keep grayscale design. We'll see if this will change later,
but at least, now we have something again.
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.
This patch removes the two instances of
gimp_rgb_luminance_uchar () and one
instance of gimp_rgb_luminance () from
the codebase.
* plug-ins/common/checkerboard.c:
Use gegl_color_get_pixel () to get the
luminance value at the same time we're
getting the RGBA value from the GeglColor.
* plug-ins/gradient-flare/gradient-flare.c:
Replace with GIMP_RGB_LUMINANCE ()
macro, which does not use GimpRGB.
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.
Previously, the "menuitem menuitem" style was cascading down
to the top menubar's subitems. This patch explicitly defines the
CSS to match the 2.10 style and prevent cascading.
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.
This handle is one of the opaque window handles as returned by
gimp_dialog_get_native_handle() or gimp_progress_get_window_handle() and
therefore it works even across processes. Now any export procedure using
the GimpExportProcedureDialog will call "plug-in-metadata-editor" as a
transient window of itself when clicking the "Metadata (edit)" button.
In particular, the Metadata editor won't be hidden by mistake when
appearing or similar issues.
Nevertheless it only works for systems where we have a transient window
implementation (so far, only X11 and Wayland, since the Windows
implementation is currently commented out because of #10229, and we have
no macOS implementation).
Note though that setting destroy-with-parent doesn't work, most likely
because the GimpExportProcedureDialog is still waiting for the Metadata
editor procedure to return (commit 54d01b5a0b), otherwise we end up with
a bad state in GIMP Protocol.
A proper solution to this will likely be to create a temp procedure from
metadata-editor to request it to close from another plug-in.
The purpose of this flag is to have some procedure arguments for which
you wish to ignore last values, or restored values. This may be needed
for arguments which are really volatile and likely won't survive a
session (or even from a run to another).
This will be used in my next commit.
Note: this is very close to GIMP_CONFIG_PARAM_IGNORE, except that this
latter is used for obsolete properties instead, so I felt that it may
not have been the best idea to mix these semantically different flag.
Also GIMP_CONFIG_PARAM_IGNORE properties are not serialized but they are
deserialized, which is not exactly what we want (in most case, it would
work the same, but it also means that if last-used values were to
contain some deprecated value for a property for which we added this
flag, there would be at least one run where a buggy behavior would
happen).
… 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).
Resolves#11980
In 443947c6, the now unnecessary g_free (drawables) was
removed from heif_av1_export (). However, it was accidentally
left in heif_export (). This patch removes it to prevent a crash
from double freeing the drawables list.
This should be enough to not "annoy" developers with repetitive ninja and
not too relevant appimagetool output. This makes easier to devs to look at
the runner log without needing to revert 9653e50e (the revert/split would
make us lose .appimage in some custom Deb pipelines and 50% of ccache hits).
Previously, we called gimp_display_shell_appearance_update ()
which updates the "Show" settings in the View menu *before*
we had updated the Display object in GimpContext.
This meant that the wrong settings were being applied when
switching images.
This patch moves the call after we run gimp_context_set_display ()
to make sure we've got the right active Display.
As I recall, this is something we in fact used to have in gimp-2-10
branch and which we lost when switching from appstream-util to
appstreamcli validation tool (the later is now recommended, but it's
also less featureful, they don't even have a relax test!). So that was a
regression in the build system.
Note that it's not just not to have to put a date too early in our
AppStream metadata, but it's also that this way, we won't forget to
update it upon release (hence shipping with a wrong release data in
metadata). Indeed, when building a non-release version, date="TODO" will
pass the test, yet moving on to a point release version, the validation
test will now fail on a TODO date.
The other way around, we were going to have the quick'n dirty exit for
the whole 3.0 stable branch, which is obviously not what we want. We
want the clean exit for all developer builds, even within a stable
branch.
I had just forgotten to add it, though fortunately (or not) it doesn't
break string freeze because the <release> description fields are not
localized right now.
Cf. discussions in #8628 and this infrastructure report:
https://gitlab.gnome.org/Infrastructure/damned-lies/-/issues/473
