A bunch of keysyms for dead keys have been added since this
code was last touched. Update the check to cover the full
range from dead_grave to dead_greek.
Make _gtk_window_unset_focus_and_default queue the changes
for after the next draw. This achieves two things: first,
it avoids invalidating css at the wrong time (e.g. when
setting child-visible during size-allocation), and second,
it defers the focus change until after the widget is
hidden, so that moving the focus has the desired effect
of picking a different, visible widget.
Fixes: #3623
gstreamers gl support included headers from this
package without depending on it. Work around this
packaging error by explicitly adding the needed
dependencies.
Visual Studio does not come with unistd.h, but Windows do have write() and
close() in io.h, so include io.h instead of unistd.h on Windows.
For MinGW, unistd.h in turn includes io.h.
Now that we have gtk_drag_check_threshold_double(), be consistent with
other draggable widgets and make sure we don't take over a drag before a
child does.
Fixes https://gitlab.gnome.org/GNOME/gtk/-/issues/3513
If multiple nested widgets have drag sources on them, both using bubble
phase, we need to reliably pick the inner one. Both of them will try to
start dragging, and we need to make sure there are no situations where the
outer widget starts drag earlier and cancels the inner one.
Currently, this can easily happen via integer rounding: start and current
coordinates passed into gtk_drag_check_threshold() are initially doubles
(other than in GtkNotebook and GtkIconView), and are casted to ints. Then
those rounded values are used to calculate deltas to compare to the drag
threshold, losing quite a lot of precision along the way, and often
resulting in the outer widget getting larger deltas.
To avoid it, just don't round it. Introduce a variant of the function that
operates on doubles: gtk_drag_check_threshold_double() and use it instead
of the original everywhere.
This was needed to work around widgets claiming event sequences on press,
by ignoring them and starting the drag anyway unless they have certain
event controllers on them.
The most visible offender was GtkButton, but since the last commit it
doesn't claim the sequence anymore and we can remove the hack.
Currently GtkButton claims the sequence both on press and on release. Stop
claiming it on press and only do it on release, allowing drags to start
from it.
This will allow to remove a hack from GtkWindowHandle.
