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.
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
To all effects each window has its own "root" coordinates system, so set
toplevels at 0,0 in that coordinate system, so root coordinate calculations
are locally right.
https://bugzilla.gnome.org/show_bug.cgi?id=729215
Delay the keyboard settings creation until we're delivering the key
press. This means we don't have to create the settings for a server that
sends us repeat information.
xdg-shell has moved on and replaced set_margin with set_window_geometry.
To properly support set_window_geometry requires a full rewrite of how
we've been dealing with toplevel windows for now, so just don't set any
margin until we can have a proper toplevel window abstraction in GTK+.
gdk_x11_display_set_window_scale() affects the interpretation of the
Xft/DPI XSETTING - it is substituted inside GDK with the value of
Gdk/UnscaledDPI xsetting. However, this change is not propagated to
GTK+ and from GTK+ back to gdk_screen_set_resolution() until the
main loop is run.
Fix this by handling the screen resolution directly in gdk/x11.
This requires duplication of code between GDK and GTK+ since we still
have to handle DPI in GTK+ in the case that GdkSettings:gtk-xft-dpi
is set by the application.
https://bugzilla.gnome.org/show_bug.cgi?id=733076
The way that GtkTextView et al pop up their context menu is to first
query to see if the clipboard has some text, and if so, enable the Paste
menu item. But since the Wayland backend hasn't had the greatest
selection and clipboard code, the callback for the clipboard got dropped
on the floor.
Add some simple code to respond to the TARGETS selection.
This makes right-clicking on a GtkTextView work fine.
Traditionally, the way painting was done in GTK+ was with the
"expose-event" handler, where you'd use GDK methods to do drawing on
your surface. In GTK+ 2.24, we added cairo support with gdk_cairo_create,
so you could paint your graphics with cairo.
Since then, we've added client-side windows, double buffering, the paint
clock, and various other enhancements, and the modern way to do drawing
is to connect to the "draw" signal on GtkWidget, which hands you a
cairo_t. To do double-buffering, the cairo_t we hand you is actually on
a secret surface, not the actual backing store of the window, and when
the draw handler completes we blit it into the main backing store
atomically.
The code to do this is with the APIs gdk_window_begin_paint_region,
which creates the temporary surface, and gdk_window_end_paint which
blits it back into the backing store. GTK+'s implementation of the
"draw" signal uses these APIs.
We've always sort-of supported people calling gdk_cairo_create
"outside" of a begin_paint / end_paint like old times, but then you're
not getting the benefit of double-buffering, and it's harder for GDK to
optimize.
Additionally, newer backends like Mir and Wayland can't actually support
this model, since they're based on double-buffering and swapping buffers
at various points in time. If we hand you a random cairo_t, we have no
idea when is a good time to swap.
Remove support for this.
This is technically a GDK API break: a warning is added in cases where
gdk_cairo_create is called outside of a paint cycle, and the returned
surface is a dummy that won't ever be composited back onto the main
surface. Testing with complex applications like Ardour didn't produce
any warnings.
Weston releases buffers almost immediately after they're done, which
means that GTK+ doesn't use a temporary surface and instead paints
directly onto the SHM backing store that Weston will use.
Normally, after painting to the temporary surface, GTK+ *replaces*
the existing backing surface with CAIRO_OPERATOR_SOURCE. However,
if we immediately paint to the backing surface, it might have junk
from the last paint in it. So clear out the backing surface whenever
somebody calls begin_paint_region().
Maybe we should just always use the temporary surface like the X11
codepath, since that prevents us from having to do weird things like
this, but oh well.
