Rename gdkdnd.h to gdkdrag.h, to go along with gdkdrop.h
This commit includes the necessary updates to the X11, Wayland
and Broadway backends. Other backends have to be updated separately.
The ultimate goal of this patch series is to split GdkDragContext into
GdkDrop + GdkDrag classes for the destination and source side of a dnd
operation.
The refactoring is meant to work something like this:
1. Introduce GdkDrop as a base class
2. Make all drop related code (like GdkEvent) use GdkDrop instead of
GdkDragContext. Move/duplicate APIs to allow that.
3. Port all drop contexts in the backends from GdkDragContext to GdkDrop
4. Delete all APIs in GdkDragContext that aren't needed anymore.
5. Make GdkDragContext no longer a GdkDrop subclass
6. Rename GdkDragContext to GdkDrag
This does nothing but disallow passing NULL to gdk_surface_begin_paint()
and instead require this context.
The ultimate goal is to split out Cairo drawing into its own source file
so it doesn't clutter up the generic rendering path.
Rename all *window.[ch] source files.
This is an automatic operation, done by the following commands:
for i in $(git ls-files gdk | grep window); do
git mv $i $(echo $i | sed s/window/surface/);
git sed -f g $(basename $i) $(basename $i | sed s/window/surface/) ;
done
git checkout NEWS* po-properties po
GdkMemoryTexture is a texture implementation for holding data in memory
(read: GBytes). You specify the GdkMemoryFormat that data is in and off
you go.
Renderers can use this to add uploads in various different formats and
don't need to fallback to GDK doing the conersion on the CPU.
Supported formats can be extended if we need new ones, for now I just
added the relevant ones for Cairo and GdkPixbuf.
The constructor is also private still, because I'm not sure we want to
export GdkMemoryFormat.
Wrappers that do from_cairo_surface() and for_pixbuf() do exist though.
Put GdkGLTexture into its own file and rename the API to
gdk_gl_texture_foo() instead of gdk_texture_foo_for_gl().
Apart from naming, no actual code changes.
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
This requires implementing a "pipe" so we can have 2 streams running:
contentprovider => serializer => outputstream
inputstream => deserializer => reader
And the pipe shoves the data from the outputstream into the inputstream.
GdkContentProvider is the object that represents local data in the
clipboard.
This patch only introduces the object and adds the clipboard properties,
it does not yet provide a way for the actual implementations to access
it.
The only access that is implemented is the local shortcut GValue access.
Add the necessary machinery into the Meson definition files so that we
can build for Windows.
Since we don't have Wayland or X support for our use case here, disable
them once we know that we are building for Windows, as they are
(otherwise) enabled by default, and enable the items that need to be
built for Windows builds.
Exclude gtk4-launch from Windows builds as that is something that
is not supported on Windows.
As we won't have gio-unix on Windows, and PangoFT2 is optional, don't use
fallbacks for them when we are on Windows (but do use fallbacks for
gio-win32, as it will be used).
Also, clean up meson.build a bit as we can just force-include
msvc_recommended_pragmas.h from GLib since we depend on GLib, and so we
can handle these warnings from msvc_recommended_pragmas.h instead.
https://bugzilla.gnome.org/show_bug.cgi?id=785210
We have to work around some ordering problems here. We still
manage to keep most of the guts in modules/input/meson.build,
so it's not too ugly overall.
(The autotools build solves this with a 'make -C ../../input/modules'
inside gtk/Makefile, but that's not something we can or want to do.)
