Drop the public filtering API. The x11 backend already has
the ::xevent signal as replacement. The win32 backend needs
a similar signal to replace filtering.
Reshuffle header inclusions in the x11 backend a little bit
to avoid a cyclic inclusion between gdkprivate-x11.h and
gdkdisplay-x11.h that is otherwise causing problems.
Remove all the old 2.x and 3.x version annotations.
GTK+ 4 is a new start, and from the perspective of a
GTK+ 4 developer all these APIs have been around since
the beginning.
The standard Vulkan SDK ships with a pkg-config file, like a modern
library should.
We should fall back to finding the library and header only for platforms
where pkg-config is not really a thing.
Based on a patch by: Daniel Stone <daniels@collabora.com>
https://bugzilla.gnome.org/show_bug.cgi?id=793181
The GDK_POINTER_MOTION_HINT_MASK enumeration value is gone, but we're
still keeping around the "is_hint" field in GdkEventMotion, even though
every backend sets it to `false` — except for the core X11 device
manager.
GdkContentFormatsBuilder is currently not introspectable, as it does not
have a GType. We can turn it into a boxed type, but we need to implement
memory management for it.
The current gdk_content_formats_builder_free() function returns a newly
constructed value, so we cannot use it as a GBoxedFreeFunc; additionally
copying a GdkContentFormatsBuilder contents would make it a bit odd, as
you could get multiple identical GdkContentFormats out of the copies.
A simple approach is to model the GdkContentFormatsBuilder API to follow
the GBytes one: use reference counting for memory management, and have
a function to release a reference, return a GdkContentFormats, and reset
the GdkContentFormatsBuilder state.
For language bindings, we can provide a get_formats() function that
returns the GdkContentFormats instance and resets the builder instance,
leaving the reference count untouched.
For C convenience we can keep gdk_content_formats_builder_free(), and
make it a wrapper around gdk_content_formats_builder_get_formats(), with
the guarantee that it'll free the builder instance regardless of its
current reference count.
https://bugzilla.gnome.org/show_bug.cgi?id=793097https://blogs.gnome.org/otte/2018/02/03/builders/
GDK has a lock to mark critical sections inside the backends.
Additionally, code that would re-enter into the GTK main loop was
supposed to hold the lock.
Back in the Good Old Days™ this was guaranteed to kind of work only on
the X11 backend, and would cause a neat explosion on any other GDK
backend.
During GTK+ 3.x we deprecated the API to enter and leave the critical
sections, and now we can remove all the internal uses of the lock, since
external API that uses GTK+ 4.x won't be able to hold the GDK lock.
https://bugzilla.gnome.org/show_bug.cgi?id=793124
The main GDK thread lock is not portable and deprecated.
The only reason why gdk_threads_add_timeout() and
gdk_threads_add_timeout_full() exist is to allow invoking a callback
with the GDK lock held, in case 3rd party libraries still use the
deprecated gdk_threads_enter()/gdk_threads_leave() API.
Since we're removing the GDK lock, and we're releasing a new major API,
such code cannot exist any more; this means we can use the GLib API for
installing timeout callbacks.
https://bugzilla.gnome.org/show_bug.cgi?id=793124
The main GDK thread lock is not portable and deprecated.
The only reason why gdk_threads_add_idle() and
gdk_threads_add_idle_full() exist is to allow invoking a callback with
the GDK lock held, in case 3rd party libraries still use the deprecated
gdk_threads_enter()/gdk_threads_leave() API.
Since we're removing the GDK lock, and we're releasing a new major API,
such code cannot exist any more; this means we can use the GLib API for
installing idle callbacks.
https://bugzilla.gnome.org/show_bug.cgi?id=793124
BTN_STYLUS3 is defined by the Linux 4.15 kernel and is sent when the
third button on a stylus is pressed. At the moment, only Wacom's "Pro
Pen 3D" has three stylus buttons. Pressing this button triggers a button
8 event to be sent under X11, so we use the same mapping here.
https://bugzilla.gnome.org/show_bug.cgi?id=790033
We have a couple of Python 3.x scripts that parse C files, and since C
does not have any encoding, we need to force one ourselves, to avoid the
case when we're running the build in a non-UTF-8 locale.
https://bugzilla.gnome.org/show_bug.cgi?id=792497
This state flag is used in several places in GTK+, for example to
ignore RESIZE_INC hints if tiled. Setting it is also necessary for
backwards compatibility with applications that changed their behaviour
when tiled, such as GNOME Terminal and its MATE fork.
Signed-off-by: Simon McVittie <smcv@debian.org>
https://bugzilla.gnome.org/show_bug.cgi?id=789357
Commit c415bef5de introduced support for the new _GTK_EDGE_CONSTRAINTS
atom. If the compositor supports that atom, however, we were always
setting the tiled state, even if no actual tiling information is
available, where the correct action is to completely remove any traces
of the tiled state.
Fix that by correctly removing the tiled state when compositor supports
_GTK_EDGE_CONSTRAINTS Xatom.
https://bugzilla.gnome.org/show_bug.cgi?id=788516
The inspector may hold on to render nodes and textures
beyond the lifetime of the widget (and thus the GL
resources). To handle this situation, allow the widget
to explicitly release the GL resources, and make
the texture available on the clent-side as a cairo
surface. This lets the recorder still show the content
after the widget is gone.
The query function for cursor sizes and capabilities
are not very interesting. At least, they are not used
in GTK+, and all backends but X11 just hardcode
made-up values anyway. So, lets drop them.
As far as possible, use per-display debug flags.
This will minimize the debug spew that we get from
the inspector if it is running on a separate display.
We should be smarter in picking a good device eventually,
but for now, we just allow to explicitly choose one. To
see a list of all devices, use GDK_VULKAN_DEVICE=list
To specify which device to use, use GDK_VULKAN_DEVICE=<number>
Instead, pass the source window to gdk_drag_begin().
Also make Wayland use this window instead of the one under the pointer
(though those 2 Windows are most likely the same anyway).
