Also use it to fix packaging of GIMP for the Windows installer (native
CI job). The CI was indeed failing to package libbrotlienc.dll,
dependency of libjxl.dll, for the simple reason that they were on
different prefixes. By calling dll_link.py on one prefix, then the
other, we were failing to grab the deeper dependency. Now with this new
ability to set several sources, the script is able to search everywhere
(with first prefix given on the CLI call as priority).
… an API that went private in GTK 3.
Note from reviewer (Jehan): this API became public again in commit
gtk@242b76a7, available since GTK 3.24.29. Before this, the function
(gdk_quartz_window_get_nswindow()) was actually still in the ABI, so we
could declare the function locally before using it. This is an ugly
workaround, but it works.
What we do is providing both solutions depending on GTK version, leaving
build warnings as constant reminders so that we remember to get rid of
the workaround when we bump minimum GTK requirement.
Cf. discussions in gtk#2452 and gimp!483.
This patch fixes a double free error due to a pointer being freed and
then not nulled out.
It appears this is corrupting memory on MacOS as the `/proc` file system
is not available and therefore multiple errors are returned.
Fixes:
(process:54873): GLib-WARNING **: 23:09:25.976: GError set over the top of
a previous GError or uninitialized memory.
This indicates a bug in someone's code. You must ensure an error is NULL
before it's set.
The overwriting error message was: Error opening file /proc/self/maps: No
such file or directory
_br_find_exe: (NULL)gimp-console(54873,0x100957e00) malloc: *** error for
object 0x103f09e80: pointer being freed was not allocated
gimp-console(54873,0x100957e00) malloc: *** set a breakpoint in
malloc_error_break to debug
I always have to search again the InnoSetup repository for the language
file. Add the link in the failed test output so that we don't waste time
searching the next time.
Also when the new lang is "Unofficial", the installer script has to be
updated as well, because these lang files must be downloaded. Add a help
text saying this as well.
Translation files were added in commit cec3c3a159 but not to the
installer and build files, which is why "gimp-distcheck-debian" job was
failing in the CI.
These warnings only happens on debug output, so it's not huge bugs, yet
it's always better not to have warnings at build time.
Most are printf format type warnings, and one is because of uncomplete
switch() cases.
While doing this cleanup, I found at least several other string leaks
in: file-compressor, file-gegl, file-pdf-save, file-raw-data, file-xwd,
jpeg-load, psd-save…
So it's quite worth it!
Note: in file-pdf-save, there is a global variable file_name which seems
to be happily leaked without caring (didn't look in details, but looks
so). I didn't fix this one which will require a bit more in-depth logics
care.
As explained in previous commits, the _peek_ call is advantageous
because:
- It is less bug-prone as we don't have to handle freeing the string. In
all the cases I changed, I even spotted at least 2 cases where we were
leaking a string (in file-mng, `temp_file_name` is never freed; and we
were also leaking in an error case of gfig).
- As a consequence of the previous point: simpler code with less lines.
- In local file cases, the _peek_ variant does not even need to allocate
an additional string.
- In other case, if we query several times the path, it is allocated
once and cached so it stays efficient.
- When possible, working on the GFile rather than on a path string may
be more robust. For instance I changed one g_unlink() into a
g_file_delete(). Actually most reading/writing should be done with the
GIO API when possible, but I didn't want to change too much code
logics on this commit.
- use g_file_peek_path() instead of g_file_get_path() in various places.
Less prone to memory management bugs (not forgetting to free in all
cases). Also it is often more efficient, especially for local files
where the _peek_ variant does not even need to allocate any memory as
path is already hanging around (and local files are the most common
use cases, I believe!).
- Also gets rid of one GFile creation with g_file_new_for_path() from
the path returned from another GFile! We can just use the same GFile
as it is not freed and perfectly usable.
Reported by Massimo, though this one is wrong, as far as I can see.
`ninja scan-build` apparently reports `result` as being returned after
being freed here. But actually since we are setting the `error` with
g_set_error() in the same time we free `result`, we would also enter the
`if (*error)` block a few lines later, which would return NULL and not
`result` anyway. I guess the static analyzer could not see that far.
Still, set the pointer to NULL with g_clear_pointer(), which should be
enough to make the static analyzer happy.
Freeing the path immediately could lead to a free-after-use error as we
used it for an error message when the file pointer failed to be created,
as reported by Massimo (thanks again!).
Using g_file_peek_path() has also other advantages, such as being less
error-prone, but also possibly more efficient. First looking at the
implementation, for local files, we already have the path around, so no
additional memory allocation even needs to happen. As for the generic
code path, it would still allocate a new string, yet cache it and reuse
it when needed later. This makes the _peek_ call much better for quick
peek-use-discard usage.
After some recent patch added to Python on MSYS2, in the same time as
they bumped from Python 3.9.6 to 3.9.7, our native Windows build started
breaking.
This patch modified `cygwinccompiler.py` to use CC environment variable
as being necessarily a single executable whereas if it were made of 2
commands (such as "ccache gcc"), the call was failing because the code
now tries to find a single command with this name (as though the space
belongs to the file name).
Therefore the line:
> File "C:/msys64/mingw64/lib/python3.9/distutils/cygwinccompiler.py", line 451, in is_cygwincc
> out_string = check_output([cc, '-dumpmachine'])
Resulted in the error:
> FileNotFoundError: [WinError 2] The system cannot find the file specified
For now, let's just not set ccache this way, even though this method is
normally meant to work and is one of the 2 officially proposed methods
(the other being to use symlinks named as compilers in priority in
PATH).
Also I'm not even sure ccache is useful at all right now (is cache
finally stored/reused between CI runs? I remember we tried to make it
happen, but I can't remember if we really had this properly in the end).
See: https://github.com/msys2/MINGW-packages/issues/9677
There's always a possibility that someone wants to use meson with
something else than `ninja` (in theory, since this is the only supported
backend atm). It also means less commands to remember for newcomers.
From Flatpak's NEWS:
> A new fallback-x11 permission grants X11 access, but only if the user
> is running in a X11 session. For applications that support both
> Wayland and X11, this can be used to ensure that the app doesn't have
> unnecessary X11 access while in Wayland, but still works in an X11
> session.
by adding special filler custom_target() build rules.
Basically, these build rules do nothing (a mere meson --version call),
but they ensure that `git-version.h` is built first, before the dependant
rc files are used in respective resource compiler build targets.
This still a nasty trick (not a proper solution), but it do the job.
See #6257 for additional information.
This workaround was placed to mitigate race condition.
It was useful for the time being, but not anymore.
Better solution will be introduced in following commit.
Reverting changes introduced in 9c6776fb.
- .gitignore and gimprc.common updated by manually running ./mkgen.pl.
- Coding style fixes in file-jpegxl:
* function names go to the line by themselves (return type on previous
line).
* avoid some overlong lines by breaking lines between parameters.
* fix some alignments.
This is based from changes in wip/release/2-99-8 branch or the Flathub
flatpak (so not necessarily released yet):
- libheif bumped to 1.12.0
- Cairo with new patch to fix#235.
Commit 086ae77929 had broken dnd of colors from toolbox's color area on
Wayland. Clearly Wayland did not like we changed focus on a click,
breaking the drag.
To fix this, do not propagate button press and release events from the
GimpFgBgEditor editor anymore. Yet, since changing colors is usually to
be used (often immediately) on the canvas, giving back the focus to
canvas still makes sense. Therefore, instead of using press/release
events, add semantic signals to GimpFgBgEditor: color-dropped,
colors-swapped and colors-default (additionally to already existing
color-clicked). Then connect to these new signals to grab focus for
canvas when relevant.
Thanks to Massimo for raising the broken color dnd feature.
