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).
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.
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.
The color for the nib handle is pulled from
the widget's background-color style.
However, this was not defined - so it was
always (0, 0, 0).
This patch adds a GimpBlobEditor CSS
class and defines the background and
border color for it to resolve the issue.
It was made impossible to paste into a channel, as this was creating a
normal layer instead. We need to use floating selections when the pasted
target is a GimpChannel type.
Note that the UX is very ugly right now for these (except for the layer
mask case as I improved this a lot with commits 04810ec95e and
28457ce337), so I opened issue Teams/GIMP/Design/gimp-ux/89 to design
further evolutions.
This is a follow-up of commit c5db158f58, where the flickering issue was
happening when creating new windows when already in multi-window mode. I
had the same issue again when I had several tabs opened in SWM and
switched to MWM. Then it would undraw displays to move them to their own
window. In the short time when this occurs, we don't want to process
events. So now I changed the "drawn" status when undrawing ("unrealize"
event) a shell.
I also changed the implementation of gimp_displays_accept_focus_events().
What we need is to check the active shell only of each window. In SWM in
particular, it is normal that non-visible tab shells get unrealized.
I had added an assert in commit 98ebe96c1f specifically to catch other
cases where we may have run gimp_ui_manager_update() with inconsistent
user context, and I failed to catch the obvious CRITICAL (the damn Error
Console was catching it!).
Anyway we had this other obvious case when creating new displays in
gui_display_create() which would trigger the ui update with still
inconsistent context.
Now I'm in fact wondering why GimpContext is simply not returning the
active GimpDisplay's image and connecting to the "image" property of set
display so that it's always synchronized. But since we are so close to
GIMP 3, and I don't want to do too important restructuration of code
(why did we do this complicated update in 2 parts? Maybe there was a
good reason…) at this point, I'll just do the simple skip for now and
look more closely at GimpContext implementation after the release.
The previous PDB generation was losing pre-formatting inside
triple-backticked blocks. In particular we were losing indentation
(which was already ugly in C, but even syntactically wrong when
displaying Python code samples). And it was also making us add
double-newlines between every code lines, which was annoying.
This updated code now leaves triple-backticked sections as-is.
Unfortunately I was completely unable to do this by modifying the
existing functions, which were modifying the input arg in-place. So I
made them into functions returning the result. But then there is another
part of code (niceargs()) where changing array contents doesn't work
properly, and worse it seems to corrupt the array somehow (because I
have generation breakage in completely-different pieces of the PDB
generation code). I believe there is some passing-by reference/value
concepts in perl which I don't quite get (they use `&`, `\` and other
symbols and even searching for these, I don't quite understand how to
use them the right way) but I've spent already too much time on this. So
since I've got something working now by having duplicate functions, I'll
let someone else from the future, who knows better perl, re-merge these
functions if they know how.
The 'help' field needs to be single-quoted so that @-values do not look
like perl variables, hence breaking GIR annotations.
Fixing:
> Possible unintended interpolation of @Gimp in string at /home/jehan/dev/src/gimp/pdb/groups/item.pdb line 64.
I double-checked the gi-docgen docs and realized the "Note:" were all on
the same line as previous text. I had forgotten it just removed one
newline. So if I want a new paragraph (double-newline in markdown), I
need 3 newlines in the pdb file.
All the functions working with object's IDs are mostly internal. They
are still made public because they can be useful and are relevant in
specific use cases (i.e. using IDs to reference items in specific
widgets, such as drop-down lists, or when temporarily storing an item as
integer, etc.).
Yet it should be made clear that these usages are the exception rather
than the norm.
I had this one case at GIMP exit where destroying editor->selection
inside gimp_colormap_editor_set_context() was segfaulting, very likely
because the widget was already destroyed so the pointer was dangling.
Therefore set a weak pointer, and clear it in dispose, so that whatever
comes first at destruction time will reset the pointer to NULL.
This fixes a never-ending flickering blocking the GUI, until a manual
focus event (such as moving a window in front) breaks the infinite loop
of handling focus events.
As Cheesequake noted in !1673, there may be cases where one would want
to run gimp_help_connect() while also setting a tooltip. So they also
run gimp_help_set_help_data(), even though the latter is implied by the
former. Worse, it makes the order matter too much because if you call
gimp_help_connect() after gimp_help_set_help_data(), the tooltip would
be removed.
Now the reason is that gimp_help_connect() was clearly made to be run on
windows whereas gimp_help_set_help_data() was for other widgets, which
usually don't need to react to F1. Yet the previous commit does add
F1-connect for the lock buttons, which kind of makes sense. So why not
just add this tooltip argument.
As a side fix, I am removing a bunch of gimp_help_connect() on each
button in the layers effect popover. Just run it once on the top
container.
This patch adds gimp_help_connect () calls before
gImp_set_help_data () to set up F1 keybind to work
properly. It also adds lock_visibility_help_id to channel
view.
Resolves#11718
Copying filters over from one image to a partial copy was broken on
multiple level by doing it on an additional loop, and assuming that the
originally selected layers and the newly created ones had the same
structure:
1. First the actually copied layers may be more numerous. For instance,
we'd also copy parent layers. Typically copying a layer under a layer
group, both the layer and its parent layer group would be in the clip
image.
2. Second, because this structure may change, the assumptions made so
that filters were not copied to the right image.
3. And as a last consequence, sometimes we could have crashes, assuming
the same structure and therefore directly dereferencing a NULL
pointer. I had such a crash when copy-pasting a layer group, while
also selecting its children layers (though this crash also got hidden
by my previous commit, but just by chance).
Instead just copy filters in the same time as layers are copied, so that
we can easily associate the filter from the correct original layer we
copied from.
app/text/gimptextlayout.c gives warnings
on MSYS2 about xres and yres not being
initialized.
plug-ins/file-tiff/file-tiff-load.c gives
warnings about read_unit not being
initialized.
plug-ins/file-bmp/bmp.c has a typo on
the label of the rgbx-8888 option for
rgb-format.
Main dev branch of GIMP always depends on the HEAD of babl and GEGL
anyway, but that's just so that we maybe have less people reporting GIMP
not building because they use a stable release version of GEGL (though
it won't take care of the case of people using an older 0.4.49 build
which also won't have the newer API).
In GTK2 and GIMP 2.10, you can use the mouse scroller to
switch between dockable tabs if you hover over the bar.
This behavior was removed from GtkNotebook in GTK3.
This patch follows other GTK3 applications in re-implementing
the behavior with a scroll-event callback.
I broke MR !1660 commits into 2 commits so that the strings are added
now (freeing this up for the upcoming string freeze), with this commit.
A next commit will be needed when we'll have the proper version update
infrastructure on GEGL side, because right now, all we can do when
filter versions don't match is ignoring the filter.
- Fix annotations for gimp_export_options_get_image() to make it
actually introspectable with the GimpImage being both input and
output. Even though the logic doesn't change much (the input image may
be overriden or not), it doesn't matter for introspection because
images are handled centrally by libgimp and therefore must not be
freed. Actually deleting the image from the central list of images
though remains a manual action depending on code logic, not some
automatic action to be handled by binding engines.
- Add G_GNUC_WARN_UNUSED_RESULT to gimp_export_options_get_image()
because ignoring the returned value is rarely a good idea (as you
usually want to delete the image).
- Remove gimp_export_options_new(): we don't need this constructor
because at this point, the best is to tell plug-in developers to just
pass NULL everywhere. This leaves us free to create a more useful
default constructor if needed, in the future. Main description for
GimpExportOptions has also been updated to say this.
- Add a data_destroy callback for the user data passed in
gimp_export_procedure_set_capabilities().
- Fixing annotations of 'export_options' object from pdb/pdb.pl: input
args would actually be (nullable) and would not transfer ownership
(calling code must still free the object). Return value's ownership on
the other hand is fully transfered.
- Add C and Python unit testing for GimpExportOptions and
gimp_export_options_get_image() in particular.
- Fix or improve various details.
Note that I have also considered for a long time changing the signature
of gimp_export_options_get_image() to return a boolean indicating
whether `image` had been replaced (hence needed deletion) or not. This
also meant getting rid of the GimpExportReturn enum. Right now it would
work because there are no third case, but I was considering the future
possibility that for instance we got some impossible conversion for some
future capability. I'm not sure it would ever happen; and for sure, this
is not desirable because it implies an export failure a bit late in the
workflow. But just in case, let's keep the enum return value. It does
not even make the using code that much more complicated (well just a
value comparison instead of a simple boolean test).
This patch creates a GimpExportOptions class in both
libgimpbase and in libgimp. Currently it is a mostly empty
object, but it will be added to after 3.0 to allow for
additional export options (like resizing on export while
leaving the original image intact)
libgimp/gimpexport.c was removed, and most of its content
was copied into libgimp/gimpexportoptions.c. gimp_export_image ()
was replaced with gimp_export_options_get_image () in all
export plug-ins.
GimpExportProcedure has a new function to set the default
image capabilities for each plug-in on creation. It also sets up
a new callback function, which allows the options to respond to
user setting changes (such as toggling 'Save as Animation' in the
GIF or WEBP Plug-in).
This is a followup of previous commit. As well diagnosed by Anders, this
value relies on "gegl:gaussian-blur" operation's argument's range.
Also adding a comment to make it easier for future developers seeing
this value.
gimp-buffer-get-image-type returns the output of
gimp_babl_format_get_image_type (), which itself returns
a GimpImageType enum. However, the PDB claims that
it's a GimpImageBaseType enum instead. This patch fixes
the documentation to match the actual output enum type.
Liam was hitting Backspace on "histogram" which is an action section and
would likely not return a proper GimpAction through
gimp_action_view_get_accel_action().
Therefore let's make sure we initialize properly the action to NULL.
The submenu labels for tool-options-popup were
hardcoded as English in GimpToolOptionsEditor's calls
to the Save, Restore, and Delete Tool Presets buttons.
This meant that these menus always fail when called in
non-English UIs, since we compare the path name and
submenu labels to only load the correct submenu items.
This patch attaches the English labels to the submenu
object so that we can retrieve it for comparison in
gimp_menu_model_get_submodel ().
