We were handling events in the wrong order,
by doing async calls for some of them, but not
for all of them.
And we were not taking into account that GFileMonitors
RENAMED events may or may not move a file on top
of an existing file.
Fixes: #3784
Document the return value and more importantly, specify that a call to
`gsk_renderer_realize()` needs to be matched with a call
`gsk_renderer_unrealize()`.
Prevents issues like https://gitlab.gnome.org/GNOME/gtk/-/issues/4625
Without building the demos, nothing gets installed into $prefix/share/icons/hicolor. Which makes running
`gtk4-update-icon-cache` on the machine causes an error. This is easily reproducible on a Windows machine with MSVC where
there is nothing pre-installed on hicolor icon theme and that makes building gtk without the demos fails with "No such file or directory".
libpng wants to receive samples in either RGB or RGBA order, whether
each sample is big-endian or not. This resolves test failures in
testsuite/gdk/memorytexture.c (and a lot of reftests) on s390x, and
probably the PowerPC family too.
Modifying the test to show the color in use and write out the PNG bytes
to a file, and running the memorytexture test on s390x, produces a PNG
that loads with the correct color values in GIMP (on an x86_64 machine),
which seems like evidence that this is the correct change and not just
compensating errors.
Resolves: https://gitlab.gnome.org/GNOME/gtk/-/issues/4616
Signed-off-by: Simon McVittie <smcv@debian.org>
If we ended up on no output at all, keep the HiDPI scale as is, as it
likely means we were on a workspace that was switched away from. By
keeping the same scale, we avoid unnecessary scale changes that would
otherwise take place if the scale when on monitors would end up being
more than 1.
clang-tidy says:
gtklabel.c:1188:15: warning: Although the value stored to 'mid' is used in the enclosing expression, the value is never actually read from 'mid'
min = mid = text_width;
^ ~~~~~~~~~~
Which seems right since mid will be assigned to at the beginning of the
next loop iteration anyway.
If we have a GDK_ACTION_MOVE, we need to delete the selection. However,
previously this only worked when the drop target and drag source were
different applications, as the selection would get messed up along the
way.
Instead, we stash marks for the duration of the operation so that we can
delete the appropriate selection when completing the move.
That way we ensure that the GL context(s) get disposed, which they
previously weren't due to them still being the current context.
This also implicitly adds testing of gLContext destruction, which
previously wasn't ever done by any test.
