GitLab

If the buffer of a cursor is NULL, for example if its an empty cursor,
just set the cursor surface to NULL as well. Not doing this we'll use
uninitialized hotspot coordinates, dimensions and scales.

https://bugzilla.gnome.org/show_bug.cgi?id=758025

Without iterating a mainloop for a bit, g_test_dbus_down() will
give us an error.

These are not supposed to be supported by gtk-doc¹

¹https://bugzilla.gnome.org/show_bug.cgi?id=758137

https://bugzilla.gnome.org/show_bug.cgi?id=758175

GTK+ is licensed under the terms of the GNU LGPL v2.1+.

GTK+ is released under the terms of the GNU LGPL v2.1+.

There is no GNU Lesser General Public License version 2; it's either GNU
Library General Public License version 2, or GNU Lesser General Public
License version 2.1.

Since it's using Lesser GPL, use version 2.1; there is no Lesser GPL v2,
as it was called 'Library GPL' prior to v2.1.

Copy-pasta from GPL instead of LGPL.

Also, there is no GNU Lesser General Public License version 2; either
it's the GNU Library General Public License version 2, or it's the GNU
Lesser General Public License version 2.1.

The code is released under the terms of the LGPL v2.1+, as is the rest
of the GTK+ code.

I didn't meant to make this different from any other file
in GTK+ when I added it.

This was showing up in glade, which creates freestanding
popovers.

Wayland allows us to receive virtual modifiers too so we can just use
them directly if the compositor does send them.

https://bugzilla.gnome.org/show_bug.cgi?id=748904

If we "release" the button first, the drag will be eventually cancelled,
we must first signal GDK_DROP_FINISHED, and then release the button so
the success status prevails.

It doesn't make a lot of sense to have this stored as data offer data,
rather together with the source_targets array, which is what we're
poking here in the end.

https://bugzilla.gnome.org/show_bug.cgi?id=758713

Dissociate ownership from our maintenance of wl_data_source objects.
The only place where ownership must be updated together is
data_source.cancelled, for the other places GDK should take care of
setting up the right ownership, even if at a different order than
we'd expect here.

This fixes GTK+ apps on wayland being locally confused about the
current selection ownership. Because gtk_selection_add_targets()
results in a wl_data_source being created, and ownership being
updated right away, early callers of this will change the ownership
even if the widget it's being called on didn't explicitly request
the selection ownership yet.

https://bugzilla.gnome.org/show_bug.cgi?id=758660

Just like it happens for window dragging, we're likely to not see the
matching button release for this event, so we must reset the controller
manually here.

https://bugzilla.gnome.org/show_bug.cgi?id=758661

After the grab is finished, we would expect an enter event, and
GDK updating internally the cursor for that window and device.
This means there is no need at all to store it separately in the
backend.

As a side effect, animated cursors are now also possible on grab
icons.

https://bugzilla.gnome.org/show_bug.cgi?id=735847

The way master devices detach from their other master counterpart is
vulnerable to infinite recursion due to the way we first recurse on
the other device before clearing the pointer, this may happen if
that last reference to the other master device is held by the
device->associated field.

https://bugzilla.gnome.org/show_bug.cgi?id=732742

Other backends take care of the cairo surface destruction in
GdkWindow::destroy. We must do the same here, or the cairo_surface
and its corresponding wl_buffer are left dangling.

https://bugzilla.gnome.org/show_bug.cgi?id=747295

Sad face for me.

tracker:uri-is-descendant/parent has the unfortunate side effect of
rendering the collation mechanisms in the database useless, so those
require full table scans to be validated.

Performing these as pure string comparisons will perform much better,
as those allow the underlying sqlite to rely on its own collation
to perform the search, which can be significantly faster with many
elements in the database.

https://bugzilla.gnome.org/show_bug.cgi?id=758407

This could produce strange warnings as it is currently passed to
tracker:uri-is-* sparql functions, as these expect no NULLs.

https://bugzilla.gnome.org/show_bug.cgi?id=758407

Just return the default value for those properties.

Testcase included.

https://bugzilla.redhat.com/show_bug.cgi?id=1281234

We can end up in situations where NULL gets passed to
get_transient_parent(). Embrace it instead of avoiding it.

https://bugzilla.gnome.org/show_bug.cgi?id=758327

If the window has not yet been created, then we can't set the invisible
cursor yet. This can happen in situations where the widget is in a
revealer with type-to-search functionality.

We were using that range for the extra buttons after left/right/middle,
while this is harmless for clients not handling extra buttons (we
used to translate those button events into scroll events in x11 anyway)
this will be unexpected for clients that do handle additional mouse
buttons themselves (eg. back/forward buttons present in some mice).

In order to remain compatible with X11, those need to be assigned from
button 8 onwards.

Also, include input.h, and stop using magic numbers here.

https://bugzilla.gnome.org/show_bug.cgi?id=758072

Commit 1266d15c also broke Xwayland, as it does the same trick
than VMWare pointers. Let's extend the heuristic to check for "pointer"
in the device name, what can possibly go wrong...

https://bugzilla.gnome.org/show_bug.cgi?id=757358

VMWare seems to create mouse devices with abs axes which confuses
our detection of single-touch touchscreens. Those have though a
name we can match on ("VirtualPS/2 VMware VMMouse"), it should
be pretty safe to assume that no real touchscreens have "mouse"
in their name...

https://bugzilla.gnome.org/show_bug.cgi?id=757358

We currently just look for a master device with input source MOUSE.
After recent changes to the way input devices are classified, xwayland
on my system comes up with a virtual core pointer that has input
source TOUCHSCREEN. This was causing assertion failures. Be a little
more careful and accept a touchscreen as core pointer, if there is
no mouse.

For @import, we want to emit the error as part of the @import statement,
not as part of the new file.

Since we are now interpreting button press events and
make our own double-click determination, we should not
handle double-click events that are generated by GDK.

https://bugzilla.gnome.org/show_bug.cgi?id=757950

When loading a nonexisting CSS file using
gtk_css_provider_load_from_file() or gtk_css_provider_load_from_path()
we would emit the error using a NULL scanner. Don't do that, because
we'll have a NULL section in that case and error handlers don't like
that.

Testcase attached.

https://bugzilla.redhat.com/show_bug.cgi?id=1277959

Signal handlers expect a section to be present, so provide them with
one.

New testcase included.

https://bugzilla.gnome.org/show_bug.cgi?id=757240

Since the change to use GtkPlacesView we don't want to show
internal storage on the sidebar.

In our case we were checking for drive_can_eject and
drive_is_media_removable.

However for some external hard drives it's reported that they
are not ejectable nor the have removable media. So the only
attribute that they have different from internal drives is that
they can be stopped.
So check for if the drive can be stopped to decide if it is
external or internal.

On the way realized we don't need to check for the mounts associated
with the volume to know if the volume can be ejected or not. So remove
that code.

https://bugzilla.gnome.org/show_bug.cgi?id=756589

DestroyWindow expects a different calling convenction so
we endup getting an error at runtime