Fix 2 "discards ‘const’ qualifier from pointer target type" warnings.

Unlike the previous 2 commits, this was not making an error but was the reason
why our code was keeping the last closed GimpImage alive a bit longer than it
should. In particular, the status bar code was keeping a hard reference to the
image until the focus changed, hence preventing the object to get finalized
longer than necessary.

Now it will also be a weak reference, so the image is immediately freed when the
view is closed.

Similar to the previous commit, but this time for the GimpAlignOptions.

Using weak pointers to make sure that the previously pointed image is still a
valid GimpImage.

Now, the CI will auto cancel jobs after a new commit is pushed and retry when
the runners fails. The first case is frequent, the last is rare but happened.

Lloyd Konneker authored Apr 09, 2024 and Jehan committed Apr 16, 2024

Copy the NULL when creating GBytes from a string.

Since the GeglColor port, gimp_drawable_get_pixel () returns
a GeglColor rather than a GimpRGB structure. We needed to
update the supporting code in ColorXHTML to handle the change.

As a follow up to the previous commit, I noticed that the pdb functions
gimp-edit-cut and gimp-edit-named-cut also incorrectly used
gimp_pdb_item_is_group.

This can be seen by calling Filters/Blur/Tileable blur when a group
layer is selected. The error message was incorrect.
We replace the call here also to `! gimp_pdb_item_is_not_group`.

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.

Library binaries are not under a hidden .libs/ directory anymore.

Per Elad Shahar, this should be v.b instead of v.r.

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.

Following 2c2e779f and 70886e55.

Following 129c1637

a22393a6 introduced redundancy while removing redundancy

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.

Our crossroad jobs are too "sensible" and prone to broke so let's go gradually.

Also, drops 'apt-cache' caching since after some experimenting with !1171
this proved to be of little use; and reorganize some dist and analysis jobs.

* 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 !1171