Both numbers are unsigned, so the result is always unsigned.
(Which also means ABS() doing a < 0 check doesn't work.)
And that in particular means that end - begin overflows to a very
large number when begin > end.
On top of that we defined a preprocessor constant to 2 different
values, but instead of checking the value, we only checked if
it was defined. Now we only define it in one place.
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.
