The loop sets empty = FALSE when there are emojis but for that
to work we need to initialize the value to TRUE initially.
Fixes: 7928532bc5c33b2c6a10bae138ebc6dca1843cb0
(cherry picked from commit 89c816a614db4083e80862b631f4b3e44aa17eae)
CI and downstream packagers have been using the Meson build for a while
now, and we checked that it's idempotent to the Autotools build.
Having two build systems in tree doesn't make maintaining and releasing
GTK any easier, even if it's the stable/frozen branch.
We not only want to use the "introspection" option: we also want to
avoid building when cross-compiling, and if the introspection tools
are not available.
GTK's main development branch already has a fairly well tested check, so
let's backport it.
Commit 0c1ea92219 took care of converting STRING/UTF8_STRING to mimetype
strings when letting selection targets known to the outer world through
wl_data_source/zwp_primary_selection_source_v1, but it missed the conversion
of those mimetypes back to the old atom strings, depending on the
application, the mimetype counterparts might not be known or handled, so
requests to paste from this app could go ignored.
Fixes: 0c1ea92219 - wayland: Translate STRING/UTF8_STRING selection atoms to mimetypes
Closes: https://gitlab.gnome.org/GNOME/gtk/-/issues/5397
Arrange for double-click-followed-by-drag to do
select by words, not select-and-dnd. This matches
the behavior in GtkTextView better and feels
intuitive.
Fixes: #2024
These tests can be run manually, but are not suitable for use as an
acceptance test, so let's not make frameworks like Debian's autopkgtest
run these when they run ginsttest-runner in the most obvious way.
a11ytests.test doesn't seem to be reliable enough to be used as a QA
acceptance criterion, and has been disabled as a build-time test in both
Gitlab-CI and Debian since 2019. a11ystate.test is not set up to be run
at build time at all, and has been marked as flaky on ci.debian.net
since 2018.
The rest of the testsuite/a11y directory seems to have been
reliable in practice, at least on ci.debian.net, so try leaving them
enabled as installed-tests.
In principle this could be made finer-grained by having a separate .test
file and a separate Meson test() for each .ui file, but that would
require more active maintenance of GTK 3.
Signed-off-by: Simon McVittie <smcv@debian.org>
At least some of the tests implemented via the accessibility-dump
executable are known to be unstable, but the tests based on separate
executables (tree-performance.c, etc.) have been reasonably consistently
passing on ci.debian.net for several years, so hopefully they are also
reliable enough for upstream CI and we don't need to mark them as flaky?
Signed-off-by: Simon McVittie <smcv@debian.org>
There are two possible interpretations of "expected failure": either
the test *must* fail (exactly the inverse of an ordinary test, with
success becoming failure and failure becoming success), or the test
*may* fail (with success intended, but failure possible in some
environments). Autotools had the second interpretation, which seems
more useful in practice, but Meson has the first.
In GTK 3.24.35, if the environment is such that the label-sizing.ui
reftest happens to be successful, the overall result of the test suite
is failure. This seems unlikely to have been the intention.
Instead of using should_fail, put the tests in one of two new suites:
"flaky" is intended for tests that succeed or fail unpredictably
according to the test environment or chance, while "failing" is for
tests that ought to succeed but currently never do as a result of a
bug or missing functionality. With a sufficiently new version of Meson,
the flaky and failing tests are not run by default, but can be requested
with a command like:
meson test --setup=unstable_tests --suite=flaky --suite=failing
This arrangement is inspired by GNOME/glib!2987, which was contributed
by Marco Trevisan.
Signed-off-by: Simon McVittie <smcv@debian.org>
