Update in particular the tarball creation steps. We now use tarballs
generated by the CI. I still leave information for doing it locally in
this howto, but mostly so that we can easily find this info for testing
or fixing dist bugs when needed. Other than this, if the CI works
flawlessly, a successful pipeline ends up with a proper tarball.
The main advantages of this approach are:
- Transparency: the full distribution process is now fully accessible on
Gitlab, from the source, through the build (including all the logs)
and up to the final tarball. Even the checksums are generated by the
CI, making it easy to recognize if different tarballs were published
on the download website or mirrors. This makes for a much safer and
trustworthy publication process.
- Less bus factor: we don't rely as much on a single person to take care
of the whole process.
- More automatization: a release still has to be prepared and verified
manually (it always will), but at least the whole tarball creation is
now automated. The next step will be to automate also the publication
on the download server.
- Update last-active parameter to 3.0 for various people.
- Add Liam Quin, lillolollo, Stanislav Grinkov, Povilas Kanapickas and
woob.
- Move myself to maintainer.
… waitpid().
My use case was when testing gimp_brush_select_new(). When doing tests,
if I let the brush dialog opened while letting the plug-in exit cleanly
otherwise, it somehow locked the process (I have stared so long at the
code and still don't understand why).
gimp_plug_in_close() would wait for it forever and the only way out was
to kill GIMP completely. I guess we could try to run waitpid() with
WNOHANG (and finally force-kill the child if it really won't exit) but
it made the whole logics extra complicated.
The logics with g_child_watch_add_full() is that we don't stop waiting
for the child and just set a callback to finalize what needs to be. Now
the worst case scenario would be to leave zombie processes dangling
around, but it's better than freezing GIMP.
Finally as a weird side effect, doing this change even unblocked the
process with an unfinished brush selector so we don't even have a zombie
anymore (at least for this specific case). All good in the end!
Last side effect: it can speed up a tiny bit the plug-in close as we
don't wait for processes anymore, which could be more visible at first
startups (when we reload all the plug-ins). Though there is nothing
scientific to my numbers, after multiple "first startups", it seems it
went down from about 3.5 to 3.2 seconds on my specific machine. Nothing
extra fancy, but we take what we can (and speeding up the startup was
never the goal of this change anyway). It doesn't affect Windows which
has its own logics to handle process termination and I preferred not to
touch it.
There are 2 parts for this fix:
- First expect the GimpPdbDialog to possibly disappear while
gimp_pdb_dialog_run_callback() is running. This can indeed happen as
this core dialog is tied to a PDB call. If the calling processus
crashes (which may happen, and has to be expected for third-party
plug-ins), then this dialog may just end up closing at anytime (signal
"plug-in-closed" from the plug-in manager which implies a
GTK_RESPONSE_CLOSE, hence dialog destruction).
To account for this, we check the dialog availability with a weak
pointer and returns the info to the caller as well.
- Don't connect to "value-changed" on the spacing adjustment because
when a crash happened, I had cases when the adjustment was finalized
while being set (crash in GTK code). This one is a bit harder to
explain (I had to look long at backtraces) but having a proper signal
"spacing-changed" on the GimpBrushFactoryView is actually much cleaner
code than relying on a public object anyway and it fixes this crash.
Note: this fix is related to my previous commit. When running
gimp_brush_select_new() from Python code, the plug-in crashed when
trying to run the callback, which also resulted into core crash (and
this part is obviously not acceptable at all).
Somehow the callback doesn't work for bindings (at least Python binding,
python plug-ins crash when the callback is called), so we'll still want
to have a closer look at this.
So far all dds images were loaded as 8 bit per channel which makes
sense for most but not all dds formats.
This commit implements loading in 16 bit for "L16" - a 16 bit
luminance channel.
In addition to that we improve security a bit by not assuming
that L16 is the only left over case but instead explicitly
checking the correct value of rmask for L16.
For other cases we now set an error with enough details
to identify the type of DDS image that needs extra
handling.
- Only publish the bz2 tarball because that's what we currently provide
on download.gimp.org (let's see in the future for the xz tarball).
- Generate also a sha512 checksum. It's better to do it on the CI rather
than on the download server, otherwise it wouldn't protect against
transfer errors (from gitlab to download server).
- Rename the checksum files to ${filename}.SHA256SUMS (512 respectively)
for easy download without name clash with the global files listing all
the previous releases.
- Disable all meson jobs for tagged releases. They are currently not
reliable and may fail randomly (see issue #6257), even though without
code problems (this is also one of the reasons why autotools is still
our official build system and meson is still deemed experimental).
It's ok for regular builds, but not for tagged builds, which we need
as reliable as possible. The really important job is the distcheck one
for tags.
When a selection exists, we are copying then pasting the selection
contents. In particular, with multi-layer selection, it means pasting a
merged result of the selected layers (like a sample merged but limited
to selected layers).
Yet when no selection exists, with a single layer selected, a cut in
particular would remove the layer fully, then a paste would copy it
elsewhere (in the same image or even on a different image). This was
still working, but not with multiple layers. This is now fixed and we
can now copy/cut then paste several layers (without merge), which is
sometimes a very practical way to move layers (sometimes simpler than
drag'n drop, especially between images).
As a consequence, the PDB function gimp_edit_paste() now also returns an
array of layers (not a single layer).
Let's increase the default size of the metadata viewer a bit.
Ideally we would add some logic to determine the width of
the first column since that one currently depends on the
length of the longest tag. However for now this change
will be enough for most cases.
The round corners script was assuming that the drawable always
was a layer, which is incorrect when a layer mask is selected.
We fix this by always requesting the active layer instead of
active drawable.
We also enable this script for RGB and GRAY with alpha
channel. Although it might not always make sense to
use this script when an alpha channel is present, there
can be use cases where it is perfectly fine.
So let the designer decide if this script is suited or not
instead of GIMP making that judgement.
This fixes the following error when building for Windows:
> error: too many arguments to function ‘mkdir’
On Windows, mkdir() is deprecated, it is an alias for _mkdir() which
doesn't have a mode parameter. The GLib version duplicates the POSIX
signature and is cross-platform (mode is simply ignored on Windows).
Closes: GNOME/gimp#541
Reviewer note: thanks to Stanislav Grinkov for cleaning up and reworking
a bit the patch, such as renaming the procedure to dir-make, as per
Kevin Cozens' review.
Removing useless condition, add a g_return_if_fail() assertion for the
only (impossible unless bug) case which we don't expect. Also set
default mindist to G_MAXLONG instead of a magic number (which was ok now
but might become a problem if some day colormap allowed more than 16-bit
per channel colors).
Finally break when we reach a distance of 0 since we won't get lower
anyway, so better stop early.
Thanks to Rafał Mikrut and Øyvind Kolås for code commenting.
We cannot just compare the drawable format with the model-type specs of
the color model. We need to include the space now.
In my case, some random screenshot converted to gray then indexed would
assert because the format is "Y' u8-space-gray-sRGB" (or for layers with
alpha: "Y'A u8-space-gray-sRGB"), hence indexed conversion failed and
ended up dark.
Looking at the documentation it is indeed red that should go
in the lowest bits and blue in the highest bits so just
reverse our code for red and blue.
We also update the version of our GIMP DDS plug-in,
this way we can catch and correct RGB10A2 images
written by older versions of our plug-in and correct
them.
With my previous commit, I improved the search action display and search
algorithm (which was returning wrong results), but we had lost showing
the non-sensitive reason in menu item tooltips. This fixes it, by
actually appending the reason, but only in the end, on the GtkWidget
tooltip (not in the action's tooltip itself).
In some cases, in particular for actions generated from plug-in
procedure right now, we were displaying the reason of the insensitivity
(typically right now, only the drawable type is cited). This was done by
appending the reason to the tooltip, separated by 2 newlines, which
resulted in extra ugly design, no nice way to style this info directly
(with pango for instance if the widget display allows it, or on a
separate info widget in a possible future, or whatnot).
Also it would mean that the action search could match a disabled action
by mistake if a search word happens to be in the reason message.
This improves the situation with the following changes:
* gimp_action_set_sensitive() now takes an optional reason string to set
the reason message.
* Same for gimp_action_group_set_action_sensitive().
* gimp_action_get_sensitive() returns an optional reason string.
* gimp_procedure_get_sensitive()'s tooltip return value now becomes a
reason (it won't contain anymore the tooltip and the reason
concatenated, only the reason for separate processing).
Jehan