If we have a fullscreen window that covers a monitor, desktop
chrome is not relevant for placing of menus and other popups.
Therefore, return the full monitor geometry instead of the
workarea in this case.
https://bugzilla.gnome.org/show_bug.cgi?id=737251
If !owner_events, the pointer window has been usually set to NULL if
the pointer fell outside the grabbing widget, but it was not being
checked that the pointer_window is actually a child of the grab
window, in which case it should be obtained as if ungrabbed.
https://bugzilla.gnome.org/show_bug.cgi?id=735749
The list of devices was being scanned over incorrectly, causing us to
never actually fetch the keymap from the keyboard, as the keyboard was
the second device in the list, not the first.
This causes us to create a new temporary keymap every time, which is
quite expensive, because it involves parsing the entire XKB
file. Scanning the list correctly will cause us to use the XKB rules
file that was passed to us.
When recursing the update area down into native subwindows we forgot
to apply the native window position. This caused us to repaint the
wrong thing in certain cases. I noticed this when playing with the
wip/gdk-gl branch, because it was triggering unnecessary repaints
of the (native window) gl widgets.
A surface may be hidden when a frame is already scheduled, which may cause
crashes on on_frame_clock_after_paint() when calling commit() on a NULL
surface. To fix this, ensure commit_pending is also set to FALSE when the
surface is gone.
https://bugzilla.gnome.org/show_bug.cgi?id=735226
Only static cursors are supported in gdk_device_grab() so far. Obey the
cursor that gdk_device_grab() specifies, which may be different to
the pointer window one. As soon as the grab is gone, the pointer window
cursor will be restored as usual.
https://bugzilla.gnome.org/show_bug.cgi?id=735831
On DnD, pointer_handle_leave may be triggered without the pointer actually
leaving the window, and pointer_handle_enter() happening after intra-window
DnD won't actually manage to update the cursor (it does nothing directly,
and to the upper layers the cursor is still the same and consistent, so no
attempt will happen).
To fix this, keep the pointer cursor on leave, and ensure it is updated
on enter. The pointer cursor will be updated to any current new one through
the enter/motion events generated if it needs be.
https://bugzilla.gnome.org/show_bug.cgi?id=735831
cairo_surface_destroy() is called after the buffer is released, for every
wl_buffer. Windows usually reference their cairo surface before rendering,
so that extra reference is consumed after the buffer is released, so do
the same with cursor surfaces and add an extra reference whenever a cursor
surface change is about to be scheduled.
Otherwise, the GdkWaylandCursor is left with an invalid cairo_surface_t,
which causes crashes the next time it is used.
https://bugzilla.gnome.org/show_bug.cgi?id=735830
On wayland the DnD surface must be created early when starting the drag
operation, so offer API for GTK+ to get the GdkWindow used as a DnD
surface on the drag operation.
https://bugzilla.gnome.org/show_bug.cgi?id=697855
The wl_data_source is retrieved from the selection object for the DnD
selection, and used to initiate a drag. When the drag is finished, a
button release or touch end event is synthesized to finish the DnD
operation after the compositor grab is gone.
https://bugzilla.gnome.org/show_bug.cgi?id=697855
The wayland specific clipboard functions have been replaced by something
more similar to the hooking the win32 backend does, which allows for just
using the default GtkClipboard code in GTK+. As a consequence, the
wayland-specific GtkClipboard implementation is now gone.
https://bugzilla.gnome.org/show_bug.cgi?id=697855
This has been made to work similarly to X11, requests for the data device
contents are notified through GDK_SELECTION_REQUEST events, the data stored
in the GDK_SELECTION property as a reaction to that event is then stored
into the wayland selection implementation, and written to the fd when
requested/available.
https://bugzilla.gnome.org/show_bug.cgi?id=697855
This implementation makes the destination side of selections work
similarly to X11's, gdk_selection_convert() triggers data fetching,
which is notified through GDK_SELECTION_NOTIFY events on arrival,
the buffered data is then available through gdk_selection_property_get().
https://bugzilla.gnome.org/show_bug.cgi?id=697855
Subsurface position is deemed part of the state of the parent surface, so
ensure wl_surface_commit() happens on the parent surface if none is
scheduled, so the repositioning takes place.
Since GLib ≥ 2.41, attempting to release an unlocked mutex will abort(),
as it happens on most systems already.
Given the lack of proper documentation on how to use GDK with threads,
there is code in the wild that does:
gdk_threads_init ();
gdk_init ();
...
gtk_main ();
instead of the idiomatically correct:
gdk_threads_init ();
gdk_threads_enter ();
gtk_init ();
...
gtk_main ();
...
gdk_threads_leave ();
Which means that gtk_main() will try to release the GDK lock, and thus
trigger an error from GLib.
we cannot really fix all the wrong code everywhere, and since it does
not cost us anything, we can work around the issue inside GDK itself, by
trying to acquire the GDK lock inside gdk_threads_leave() with
trylock().
https://bugzilla.gnome.org/show_bug.cgi?id=735428
The latest implicit grab serial is used in order to start the compositor
grab, If it belongs to a touch event, remove that touch sequence, as the
rest of the sequence will be gone for good.
This avoids stale sequences (and implicit grab info) after a window is
moved/resized.
https://bugzilla.gnome.org/show_bug.cgi?id=731380
_gdk_wayland_device_get_button_press_serial() has been replaced by
_gdk_wayland_device_get_implicit_grab_serial(), which takes a touch/pointer
event and figures out the relevant serial, and
_gdk_wayland_device_get_last_implicit_grab_serial() which returns
the most recent serial.
The button press serial was currently used when operating popping up
xdg_shell/surface popups and window menus, so this is now touch aware, of
some sort.
https://bugzilla.gnome.org/show_bug.cgi?id=734374
If the compositor sends a keymap that fails on "compilation",
xkb_keymap_new_from_string() returns NULL, which makes xkb_state_new()
crash when assuming there is a keymap.
In these cases, gdk must remain with a xkb_state to handle modifiers/keys
properly, so warn about the invalid keymap string, and keep the previous
keymap (currently initialized to "us")
https://bugzilla.gnome.org/show_bug.cgi?id=735389
