It won't stand true anymore that the GdkEventType argument is the
first field of the GdkEvent* structs. All callers have been updated
to use event->any.type instead.
Instead of just passing the GdkContentFormats, we are now passing the
GdkContentProvider to gdk_drag_begin().
This means that GDK itself can now query the data from the provider
directly instead of having to send selection events.
Use this to provide the private API gdk_drag_context_write() that allows
backends to pass an output stream that this data will be written to.
Implement this as the mechanism for providing drag data on Wayland.
And to make this all work, implement a content provider named
GtkDragContent that is implemented by reverting to the old DND
drag-data-get machinery inside GTK, so for widgets everything works just
like before.
We now have a GdkX11Display::xevent signal that gets emitted for every
XEvent and allows you to interrupt processing via TRUE/FALSE return
values.
These return values to correspond to GDK_FILTER_REMOVE and
GDK_FILTER_CONTINUE respectively.
The GDK_FILTER_TRANSLATE case from gdk_window_add_filter() is now meant
to be handled via gdk_display_put_event().
This is in preparation for DND.
It moves a lot of code from gdkclipboard-x11.c to
gdkselectionoutputstream-x11.c to untangle it from GdkX11Clipboard
usage.
Instead, pass the actions as part of gdk_drag_begin() and insist DND is
always managed.
A new side effect is that gdk_drag_begin() can now return %NULL.
This fixes stuttering in animations that rely on the regularity of
gdk_frame_clock_get_frame_time.
https://bugzilla.gnome.org/show_bug.cgi?id=787665
BEFORE
gdkgears:
58 FPS and visibly stuttering
gnome-maps on a 59.95Hz monitor:
"paint" g_get_monotonic_time +17278μs, gdk_frame_clock_get_frame_time +17278μs
"paint" g_get_monotonic_time +17449μs, gdk_frame_clock_get_frame_time +17426μs
"paint" g_get_monotonic_time +17620μs, gdk_frame_clock_get_frame_time +17600μs
AFTER
gdkgears:
60 FPS and smoother
gnome-maps on a 59.95Hz monitor:
"paint" g_get_monotonic_time +18228μs, gdk_frame_clock_get_frame_time +16680μs
"paint" g_get_monotonic_time +15010μs, gdk_frame_clock_get_frame_time +16680μs
"paint" g_get_monotonic_time +17134μs, gdk_frame_clock_get_frame_time +16680μs
This is the replacement for selection usage.
Backend implementations for X11 (missing support for backwards compat
formats like COMPOUND_TEXT) and Wayland are included.
GTK code should be adapted to use gdk_drop_read_*() functions instead
of gtk_drag_get_data().
If we fail to connect to the session bus, it would be a bit silly to
immediately try and use that NULL connection.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=668590
In order to map a window with the correct initial parent-child
relationship when a modal dialog is set up to be a child of an imported
foreign window, the relationship must be set up before the window is
mapped.
In order to do this, if a window is not yet mapped, postpone the
relationship setup until when the window is eventually mapped.
https://bugzilla.gnome.org/show_bug.cgi?id=791062
Traditionally (and on most backends) there's a single master pointer driven
by all pointing devices. The notable exception is Wayland though, where
master pointing devices are created per capability in the case of
pointer/touch, and one for each drawing tablet.
This function call makes it easy to access all these.
https://bugzilla.gnome.org/show_bug.cgi?id=790920
We are using `path` unconditionally, but it can be conditionally filled.
To avoid inconsistent internal state, and a compiler warning, let's
assert that the variable is always set.
This API allows specifying a GType and va_args of a value of that type
to set the clipboard contents. This massively simplifies setting weird
object types into the clipboard.
2 example patches included in this patch are the GtkTextBuffer and the
file list in the file chooser.
Using gobject-introspection, this should work without specifying the
type, so that you can literlally say
clipboard.set ("Hello World")
or
clipboard.set (pixbuf)
which is why I've also marked all other setters as (skip). They just
exist in C as wrappers for type safety reasons.
This is in preparation of using input streams to show that these
coordinates aren't needed most of the time and can otherwise be saved
during GtkWidget::drag-drop.
