No.
This fix is not that much better, but I'm too tired to fix stuff
like this properly.
And the Cairo renderer did at least work everywhere during 4.x
Somebody came up with the great idea of content types, which
are just like mime types, only that they aren't on Windows.
So if we want a working testsuite that actually works on Windows,
we cannot mix them up.
Passing on-stack items to a thread in a function that exits right
after spawning the threads is a bad idea:
By the time the thread starts up and reads the values, the stack might
be in use for other stuff.
So instead of putting the items on the stack, just read them out of the
clipdrop struct.
Logging them with `g_print()` will write to stdout, which can interfere
with machine-readable output, for example when gnome-control-center
displays the GPU/driver name.
Resolves: https://gitlab.gnome.org/GNOME/gtk/-/issues/7093
Signed-off-by: Simon McVittie <smcv@debian.org>
meson has a tendency to dump wrap files of subprojects into this directory.
So we have to ignore them when using wrap files.
I think meson should put them into its builddir, but oh well...
Update the requirement in meson.build and the CI runners to meson 1.2
This keeps things in line with glib and avoids unexpected suprises from
using meson versions that are way too old.
If we get an error from the message bus (dbus-daemon or dbus-broker),
for example ServiceUnknown if Avahi is not installed or perhaps
SpawnFailed if the service is disabled, it is mapped to a GLib GError.
The errors typically emitted by the message bus belong to the GDBusError
domain, but if nobody has registered the G_DBUS_ERROR domain yet,
then they might be mapped to G_IO_ERROR_DBUS_ERROR instead.
Previously, this code ignored G_IO_ERROR_DBUS_ERROR, but emitted a
warning if the error happens to have been mapped to G_DBUS_ERROR.
This resulted in action-at-a-distance: an unrelated component
triggering registration of the G_DBUS_ERROR domain would make printing
dialogs log the warning. This seems undesirable, and in particular it
can cause test failures, because GLib's test framework makes warnings
fatal by default.
Signed-off-by: Simon McVittie <smcv@debian.org>
If we get a G_IO_ERROR_DBUS_ERROR here, we shouldn't make too much noise
about it by default, but it's still a useful data point for debugging
and diagnosis.
Signed-off-by: Simon McVittie <smcv@debian.org>
When determining the number of selected children, we were properly
counting only items, but in the rest, we were confused by row headers.
Because the GtkListItemBase methods did not throw a warning on inappropriate
pointer type passed, we happily passed the row headers, got some private
data object as the wrong type, and then returned nonsense, for example, 2
for gtk_list_item_base_get_selected.
We want to use the default renderer.
This env var was introduced in
commit df4c57c001 to work around an
inspector bug.
But it's not 2020 anymore and Vulkan actually works now.
With the swapchain maintenance extension, we have a way to release
the acquired swapchain image before recreating the swapchain, in
the VK_SUBOPTIMAL_KHR case. Use it.
Tested by toggling fullscreen in the bloatpad example, which causes
mesa to return VK_SUBOPTIMAL_KHR (since dmabuf modifiers change).
If vkAcquireNextImageKHR returns VK_SUBOPTIMAL_KHR, the semaphore
is in use, but vkDeviceWaitIdle will not wait for it, since it is
not associated with a queue. Make sure that is the case, so we don't
run into a validation error when we try vkAcquireNextImageKHR with
the same semaphore, after recreating the swap chain.
See https://github.com/KhronosGroup/Vulkan-Docs/issues/1059 for
some related discussion.
Fixes: #7079
This is an upstream protocol providing equivalent functionality as the
system bell request in gtk-shell.
This commit includes a copy of xdg-system-bell-v1.xml, since we don't
depend on wayland-protocols 1.38 yet.
The `gdk_color_finish()` calls are currently after the `return`,
so they are never executed. Move the `return` below the cleanup
code to avoid that.
Fixes: bd3d1f7715 ("gsk: Add private border node api")