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.
Instead of using should_fail, we can 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
by running a setup that does not exclude them, with a command like:
meson test --setup=x11_unstable --suite=flaky --suite=failing
As a bonus, now that we're setting up setups and their excluded suites
programmatically, the gsk-compare-broadway tests are also excluded by
default when running the test setup for a non-broadway backend.
When running the tests in CI, --suite=gtk overrides the default
exclude_suites, so we have to specify --no-suite=flaky and
--no-suite=failing explicitly.
This arrangement is inspired by GNOME/glib!2987, which was contributed
by Marco Trevisan.
Signed-off-by: Simon McVittie <smcv@debian.org>
Add missing #define g_memdup2() for gdksurface-broadway.c in case of enabled
broadway-backend as used otherwise.
Copy static would_drop() replacement for g_log_writer_default_would_drop()
from gtk-builder-tool.c to gtk-reftest.c
It allows to specify the resize mode of the paintable inside the
GtkPicture allocation. This also deprecates the keep-aspect-ratio
property.
Fixes#5027.
This checks mainly that we do the right thing wrt PangoAlignment
weirdness.
0.25 and 0.75 are set to 0.0 and 1.0 currently because of Pango
limitations (and no desire to manually move lines).
But if that were to be fixed, both the ref and the test should update in
the same way and things should just keep working.
This brings back a subset of what quit-mnemonic.ui tested for, but
trying a lot harder to trigger the label overdrawing its allocation,
which will cause the text to be cut off when clipping is happening.
It should not be an issue at all with GTK4, but keeping that test around
is a good idea.
I can't quite figure out what this test was meant
to test, and how to make it do so in a way that
does not fall afoul of rendering issues in the GL
renderer and rounding differences in pango.
Can't win with reftests.
Calling functions inside a g_assert() means those functions will be
compiled out when building with G_DISABLE_ASSERT.
This fixes the release job in the CI pipeline.
If halign=fill, force adjustment to height-for-width.
If valign=fill, force adjustment to width-for-height.
Otherwise look at request mode.
This way we don't try to adapt the filled dimension and only adjust
the one that is not set to fill.
g_log_writer_standard_streams just puts all the logs
out onto stderr and stdout if we don't stop it. Pango
recently grew a bunch of g_debug calls, and those were
now showing up, making all the reftests fail.
Assume a vbox with 2 wrapping labels saying
Hello World
Hi Ho
being measured for their minimum width for 3 rows of text.
This should be layouted like
Hello
World
Hi Ho
and measured accordingly.
However, previously this was layouted as
Hello World
Hi Ho
with 1.5 lines being assigned to both labels.
That will obviously not compute the above wrapping which clearly
results in a smaller min width.
A reftest testing exactly this was included.
Having a short text and a large max-width-chars should request the
natural width of the text, not the limit from max-width-chars.
This caused huge message dialogs.
Reftests added.
Use a label that is long enough to require wrapping and force it into a
hardcoded width. Use a sentence where all the words have the same size
to not get unwanted wrapping behavior.
Also append a 2nd row to check that the first row gets the proper height
allocated.
Found by Marco Melorio.
For size -1 in the opposite orientation, GtkBoxLayout used to measure
the children based on their min size in the box's orientation instead of
-1. That wasn't really intended, but was a side effect of how the sizing
code did (not) distribute extra size above the minimum size.
This is clearly not what we want.
What we want is measuring the orientation as is for size -1. Then we
want to just take the maximum of all children and use that.
A reftest is incldued that ensures a vbox wraps a label just like an
hbox does.
The old code couldn't properly do height-for-width because it only
computed the widest and smallest layout instead of looking at the actual
passed in for-size.
The label-sizing reftest has been adapted as the label code is now smart
enough to always display the whole text and no longer requests a too
small width-for-single-row when wrapping.
This reverts commit ba44e7a228.
The change was meant to revert to old GTK3 behavior but it actually
broke new GTK4 behavior that is in use where max-width-chars is used to
determine an ideal size, but where we don't want to limit the width to
that size.
So what happens is the reintroduction of GTK3-style lots of whitepsace
bugs, and we really don't want those.
We also don't want to break backwards compat if we can avoid it.
So let's revert this.
The reftest that was made for this purpose has been adapted.
Fixes#4399
If a URL can't be loaded, we might end up with a NULL file. Handle that
case properly by creating an invalid image instead and don't crash or
complain to stderr when files are NULL.
This was broken since 0886ade182
A new reftest has been included. We need a reftest instead of a
CSS parser test, because the error only becomes visible when
compute()ing the actual image.
Fixes#4373
Have square images in the following sizes:
* 20
* 100
* 150
* 200
* 300
and place them in a can-shrink Picture allocated at the sizes:
* 200x100
* 100x200
and set align to center/center.
That's 10 combinations and they should all do the right thing.
We were only applying <binding> elements when the
object is constructed, which can be triggered by
various things (e.g. a <style> element). Defer
this until we reach </object>, so we can be sure
that we pick up all the bindings.
Testcase included.
Fixes: #4147
The GtkBuilder parser constructs the object e.g.
when handling a <binding> element. There may be
more <property> elements after it, which we were
just not applying. Fix that by always applying
property when we see </object>. To do that, we
need to track the applied status per property.
Test included.
Fixes: #4208
