The user data passed when exporting a Wayland window was supposed to be
freed using the destroy_func, as is commonly done. This was previously
broken, as the user data was just NULL:ed when exported, and only
actually destroyed when unexporting before having exported.
While e016d9a5db fixed this, it introduced
a regression, as GtkWindow was nice enough to free the memory anyway
after having received the exported handle, causing it now to double
free.
https://bugzilla.gnome.org/show_bug.cgi?id=782109
Otherwise in GC-ed environments the `g_source_remove` call during
disposal might be called on an already removed source, which results in
unnecessary console output.
https://bugzilla.gnome.org/show_bug.cgi?id=778301
5bb12474d9 removed the dnd window movement code to let
the gdk backends handle the window movement instead. While this
works for X11/wayland the win32 backend still uses the unmanaged
interface and expects the window movement to be handled on the gtk
side. This restores the functionality in case the dnd is unmanaged.
This fixes the drag window on Windows being stuck in the top left
corner instead of following the drag position.
https://bugzilla.gnome.org/show_bug.cgi?id=781737
Creating with `gtk_popover_new_from_model` should be exactly the same as
if via `gtk_popover_new` plus `gtk_popover_bind_model`.
Also remove the style if the model is unbound at any point.
Try text/plain;charset=utf-8 first, before falling back to
X11-isms like UTF8_TEXT. This makes things work on Wayland
compositors that don't carry a heavy X11 legacy around.
https://bugzilla.gnome.org/show_bug.cgi?id=781814
GSK has various enumeration types that are currently not used; while
they may go away, currently they are built and introspected. If we want
the introspection machinery to work, and still use static libraries to
build GDK and GSK into the GTK shared library, then we need to reference
the get_type() function of these enumeration types somewhere, to avoid
the linker discarding it, and thus breaking the build.
As luck would have it, we have an autogenerated bit of C that refers to
all the get_type() functions in the library; if we add the GSK types to
it, then we get the reference we're looking for, and the build succeeds.
We're mixing a lot of styles in the Meson build files. This is an
attempt at making everything slightly more consistent in terms of
whitespace and indentation.
We need to check if the linker flags we use are available, depending on
the platform, and we need to ensure that the shared library is
versioned appropriately.
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.)
Add back dependencies on libgdk_dep and libsk_dep which are declared
dependencies. We removed this before because these declarations had
link_with: lines that dragged in the static libgdk.a and libgsk.a libs
which are linked into libgtk-4.so anyway and thus shouldn't be used
when linking internal exes/tools against libgtk-4. Remove the static
libs from the declared dependencies and have libgtk link those in
explicitly, so that the declared deps now just provide all the built
dependencies and include dirs and such for declared libgtk_dep users
such as the internal exes/tools, which want all the generated gsk/gdk/gtk
headers to exist before attempting to compile anything against the
gtk+ headers.
gdk and gsk are no longer separate libs but part of gtk now, so any
Gtk+ user should just link to gtk, there's no need to additionally
link against all those static helper libs that go into the gtk lib.
This means we need to specifically add confinc to include_directories
in more places to make sure the right config.h (i.e. ours) gets
included and not a subproject's like graphene's config.h.
Not dragging in static libs also fixes the issue of all executables
having to be relinked for any and all changes. With this change
it's super-fast now and can be skipped for most changes that don't
touch the external ABI.
