Calling gimp_selection_float from a Python plug-in could make it crash
with an error like Calling error for procedure 'gimp-selection-float':
Item x cannot be used because it is not a group item.
This is caused by an incorrect check for group layers.
gimp_pdb_item_is_group returns an error when the condition is False,
while we only want an error when a group layer is selected (True).
Thus we need to use gimp_pdb_item_is_not_group, which returns an error
when the item is a group, which is what we want.
These function names are a little confusing, we might need to think
about better naming sometime.
I added C/Python tests for this function, so that we can test whether
this works correctly.
This is now back in sync with how it used to be up to GIMP 2.10. Basically our
API version should always be <major>.0 in the shared libraries naming, as well
as in pkg-config and docs. Otherwise we would break library compatibility with
every minor version bump.
Code that checked if an image was NULL was run
*after* the variable was used in a function,
gimp_image_resize_to_layers (). This patch moves
the NULL check before the function call is made.
Additionally, we now verify there are at least two axis
before trying to access indexes in the naxis array.
Since !1171 the 'before_script' was being used by me for organization, but
this is at least unexpected to "mainstream" .yml pratice and can be wrong.
For example, the universal variables can't be properly used this way.
So, let's use 'before_script' only for the (official) purpose: save code.
Resolves#11292
Since the GimpProcedureDialog port, the "settings-data"
parameter has been used to save and load the selected
color map. However, the parameter was not being updated
when the user switched colormaps in the GUI - therefore, it
always used the "Custom Gradient" option.
This patch updates the "settings-data" parameter after the
change to resolve the issue.
This isn't directly related with #10922 and does NOT affect 32-bit support.
After talk with @Jehan, author of 'crossroad' and main dev of crossbuilds,
we decided that the x86 crossroad builds can be dropped by these reasons:
1) 32-bit crossbuilds weren't being built. They are used since c8ec0ae7 but
after the native 32-bit builds they ended in a state that they are the only
pipeline that isn't automatically triggered in any way, a complete limbo.
2) 32-bit crossbuilds weren't being autonomous. They are not working fine
with wine32 so the win-x64-cross artifact is a 'need' and now debian-x64,
so we were spending way more time fixing than using the 32-bit cross jobs
(sometimes the 32-bit cross jobs are just broken and we even noticed).
We have other jobs not autonomous but they don't have additional bugs
like not being able to build with .mng and .wmf (32-bit cross only bugs).
---
The x64 crossbuilds will continue to be supported. They are very useful to
develop on Linux, and test MRs on Windows. I'm an assiduous user of them :)
Resolves#11283
In the GUI, set_flame_preview () is connected to GimpProcedureConfig's
"notify" signal. However it is not disconnected afterwards, so it runs again
after the plug-in is finished and the "setting-data" parameter is updated.
Since the preview area no longer exists, this causes a crash.
This patch resolves the issue by storing the callback ID and then disconnecting
after the GUI is closed.
This was added in a22393a6 and e96b751e, following old 2_build-gimp-msys2.sh.
But, according to my tests (local and in the CI, in both Debian and Windows),
meson creates this in setup time so the manual folder creation is redundant.
Resolves#11250
In 2.10, we explicitly hid "dockable-preview-size-menu", the submenu
for Preview Size, if there were no previews to set sizes for in the
dockable dialogue. In 2.99, this code was removed as part of the
GAction port and code clean-up.
As a result, the Preview Size submenu is always visible even if the
options have no effect on the display. To restore the 2.10 behavior,
we set each Preview Size option's visibility. If all options are hidden,
the submenu does not appear.
* Move common things to the new .default section extensible for all jobs
* Reorganize order of job elements to be way more consistent and rational:
from general (pipeline/rules) to specific (job artifacts) in a liner way
* The order of rules was changed to be a bit more easier to understand
- Drops 'dependencies' which is redudant, and 'needs' have more options
- Drop apt-cache which lost use and it is sometimes troublesome to cache
+ First try to boost the use of ccache in all build jobs, when possible
+ Fix the problem of non-failing jobs introduced by GNOME/gimp!1171
Build for macOS on CI breaks with:
> ../gimp3-2.99.19/libgimpwidgets/gimppickbutton-quartz.c:210:45: error: use of undeclared identifier 'monitor_profile'
> space = gimp_color_profile_get_space (monitor_profile,
In case there are no fonts loaded (which may happen in particular when starting
with --no-fonts), we need to make sure that font is initialized to NULL so that
we can return the standard GimpFont object and not a broken pointer.
Thanks to Idriss for the additional diagnosis, which would hopefully complete
commit 5dc86277e6 and take care of #11219.
This commit uses definitions and references to reduce repetition of CI code.
Some people (like the GitLab devs?) prefer (almost imposes) this to be done in
multiple .yml's using 'worfklow:' but this makes the CI way more complicated
and very slow to read. So, let's just keep simple in one human readable file.
---
Other changes are:
- The custom native arch pipelines now they always generate a .zip package.
This helps to ensure that everything is in place and facilitate testing;
- The pacman update (-Syyuu) was removed since it is auto done by runners;
- The ccache config was moved to .yml. This does NOT affect local builds
since meson saves ccache by default for user in '%LocalAppData%/ccache'.
Previous code would only set the class member when we were actually
loading fonts, so we ended with code paths where the member was NULL.
Fixes:
> GIMP-CRITICAL: gimp_container_get_n_children: assertion 'GIMP_IS_CONTAINER (container)' failed
It should hopefully also fix#11219 (though I couldn't reproduce this
failure).
Resolves#11256
A GError variable was created but not passed to
file_open_with_display () when opening recent files.
As a result, if an error did occur the variable would be
used while it was still NULL. This patch fixes this
by passing a reference to error as the last parameter
of file_open_with_display ().
We compute the size of the mipmapped layers wrong. We assume that
width, height are always exactly a power of 2, which is the normal case
for dds images. See issue #11256.
Since other sizes are possible, we adjust this by computing the width
times height times bytes per pixel of the current mimmap level.
Resolves#11075
In the DrawableChooser pop-up, choosing an image without
also picking a layer or channel causes the pop-up not to
reappear on subsequent attempts to click it. This is because
the callback is only recreated when the drawable is updated,
and choosing just an image does not update the drawable.
For 3.0, we'll set the Okay button to insensitive unless a layer
or channel is picked.
I added a few improvements to how we load the Photoshop layers:
- When included from TIFF, we forgot to decrease the data_length for
the parts we already read.
- Also when included from TIFF, we need to skip the global layer mask
info.
- The block length for the layer data needs to be a multiple of 4.
- Catch an invalid data condition where block_len is greater than
total_len. This could cause a change total_len to a very large
value, so protect against that.
When loading Photoshop metadata from TIFF images, the size of the data
in the temp file was often incorrect.
This happens because run_mode is usually GIMP_RUN_INTERACTIVE when
run from within GIMP. In interactive mode, the last saved config values
take precedence over the ones set in the function call, which is not
what we want in this case.
We would prefer to use interactive here, because then we can show a
dialog with a list of unsupported Photoshop features that were found
inside the image.
For now, we will use GIMP_RUN_NONINTERACTIVE and accept that we can't
do that at this time. This way we will at least have the correct values
when processing the Photoshop data.
The clipping path values are all 2 bytes, but we were only reading in
1 byte for each value. In addition to that, the path_flatness_fixed
value was not converted to the correct Endian representation.
Since these values are usually 0 and get clamped to valid values, this
went unnoticed until now.
Fixes 2 such warnings:
> warning: format ‘%i’ expects argument of type ‘int’, but argument 5 has type ‘size_t’ {aka ‘long unsigned int’} [-Wformat=]
As well as:
> warning: conversion lacks type at end of format [-Wformat=]
And:
> warning: no previous declaration for ‘reset_output_port_struct’ [-Wmissing-declarations]
Jacob Boerema