Instead of calculating the discrete scroll deltas in
GtkEventControllerScroll, move that code to the event constructor and
access the precalculated values using gdk_scroll_event_get_deltas.
Refactor, no functional changes.
Starting with Linux Kernel v5.0 two new axes are available for
mice that support high-resolution wheel scrolling: REL_WHEEL_HI_RES and
REL_HWHEEL_HI_RES.
Both axes send data in fractions of 120 where each multiple of 120
amounts to one logical scroll event. Fractions of 120 indicate a wheel
movement less than one detent.
The 120 magic number is a copy of the Windows API, so this new
constructor can be used both in Linux >= 5.0 and Windows >= Vista.
Add missing #define g_memdup2() for gdksurface-broadway.c in case of enabled
broadway-backend as used otherwise.
Copy static would_drop() replacement for g_log_writer_default_would_drop()
from gtk-builder-tool.c to gtk-reftest.c
Even though the argument is non-nullable, GTK sometimes incurs in that
by itself by destroying the surface while the event is in flight. This
is the case of popping down a GtkDropdown. When this happens we simply
ignore the crossing event, but we should let it through instead, the
compositor did not send it in vain and we possibly still have pointer
state to undo.
Drop the surface checks, so that the event is propagated along GTK.
Following what was done for pinch/swipe events, give hold gestures their
own distinct sequence as well. Without this it was NULL, which was already
distinct to other touchpad gestures.
If we get an invalid TARGETS reply, we might not have a valid 'type',
which ends up as NULL and segs in the g_str_equal.
(This is probably fallout from my fix 506566b6a4, which I still
can't reproduce reliably, so the last one just moved the seg a bit
further along, and we still don't know who is sending a bad TARGETS).
This corresponds to:
https://bugzilla.redhat.com/show_bug.cgi?id=2062143
C API users can keep dealing with the implicit equivalence of
GdkFileList and GSList, but language bindings have no idea that one type
is another, and none of them exposes GSList as a type anyway, so they
will need a way to construct a GdkFileList.
Instead of making GdkFileList mutable, and re-implement GSList, we only
provide a constructors pair that lets you create a GdkFileList from a
linked list or from an array.
DnD under Windows needed 3 fixes to work with Gtk.DropTarget.
1. The droptarget_w32format_contentformat_map list never gets
filled so the gdk_win32_drop_read_async throws
"No compatible transfer format found".
This is an easy fix and done the same way in the win32 clipboard code.
2. After a drop no gdk_drop_emit_leave_event gets emitted.
This causes a second drop to trigger a bunch of assertion
'self->drop == drop' failed because the first drop is still active.
This is also an easy fix and done the same way by the macos backend.
3. Handling gdk_drop_status/gdk_drop_get_actions interaction.
In gtk_drop_target_do_drop the code
```gdk_drop_finish (self->drop, gdk_drop_get_actions (self->drop));```
calls the finish operation with the actions of the drop which triggers
```g_return_if_fail (gdk_drag_action_is_unique (action));```
in gdk_drop_finish. The code assumes that GdkDrop::actions gets
narrowed down by calling gdk_drop_status. This is hard to assure
because at the same time gdk_drop_get_actions is used by
gtk_drop_target_accept to figure out if a drag is accepted.
GdkDrop::actions serves a double purpose here as the supported source
actions and the currently agreed on action. Both the x11 and the
wayland backend get this wrong somewhat too. Under wayland/x11 when
a drag coming from a source that supports both MOVE and COPY is
first hovering a drop target that only supports COPY it is afterwards
no longer accepted by other drop targets only accepting MOVE.
Under x11 this is permanent for this drag but with wayland the drag
recovers when hovering other widgets. The win32 backend now sets the
supported source actions before any enter/move/drop and narrows them
down in gdk_win32_drop_status.
The patch only touches the win32 backend and fixes all three issues,
for me restoring DnD under windows.
Closes#4498
This serial should be that from a button press/touch down/etc, use
the last implicit grab here, which will presumably be from the same
device that triggered the event.
Closes: https://gitlab.gnome.org/GNOME/gtk/-/issues/5048
The XDND suggested action is a relic from when the source would control
the action for a drop. With the new GtkDropTarget the target decides
the action (not the source). That means the all of the returned
results from the ::enter and ::motion handlers will be unexpectely
ignored. Prefer to use the preferred action over the x11 suggested action.
Fixes: https://gitlab.gnome.org/GNOME/gtk/-/issues/4259
gdk_x11_drop_update_actions() sets actions to
drop_x11->suggested_action when !drop_x11->xdnd_have_actions
and then sets it again to drop_x11->suggested_action if it is.
If xdnd_have_actions is true use xdnd_actions.
Don't return to the main loop, instead force a run of the paint idle.
The paint idle will know to skip all the phases that aren't requested.
This is critically important becuase gdksurface.c assumes the
FLUSH_EVENTS and RESUME_EVENTS phases are matched, and we cannot
guarantee that if we return to the main loop and let various reentrant
code change the frame clock state.
This would lead to bugs with events being paused and never unpaused
again or even crashes.
Fixes#4941
If we take the early return we don't unscale this at the bottom of the
function, causing wrong coordinates in HiDPI screens.
This bug also affects GTK3 (I noticed this running Firefox tests on X).
The GdkToplevelSize struct already has the concept of "bounds", which
means the largest size a window should reasonably have. It's practically
the equivalent of the monitor the window is intended to be mapped on,
with the "struts" (e.g. panels) cut out. It's used by GTK to use this
information to calculate a default window size that is "lagom" (swedish;
not too large, not too small).
Simplify the API to just return the requirements that the user
has asked for. The rest of the code was undocumented and previously
used as a buggy source for a default value from internal code.
Since the buggy code is now fixed, remove all unnecessary cruft.
There are two reasons for this:
* First, the refactored realize code now makes sure that no
context with unsupported version is ever created.
* Second, this code could bump into false possitives and negatives, since
the user is not requested, nor expected to set_required_version
in any specific order relative to set_allowed_apis. Therefore,
some version could be rejected or accepted based on a set of
allowed apis that the user has not yet correctly configured.
Mimic the behavior of the egl context creation by stablishing
some sane logic for the api and version used. Split the decision
of the type of context (api, legacy) and the creation of a context
of a certain version and all its properties.
By setting and then getting the required version in a context, the code
was not respecting user requirements. Instead, simply get the requested
version by the user clipped by the requirements (display version)
It is useful for backends to get user set preferences while
ensuring the correctness of the result, which will be always
greater or equal than the minimum version provided
When loading cursors at scale, we expect the
cursor images to have a size of scale * size.
If we don't find such images, load them at their
unscaled size and scale them up ourselves.
Without this, cursors will appear in unexpected
sizes depending on scales and themes.
Related: #4746
On Wayland it is a protocol violation to upload buffers with
dimensions that are not an integer multiple of the buffer scale.
Until recently, Mutter did not enforce this. When it started
doing so, some users started seeing crashes in GTK apps because the
cursor theme ended up with e.g. a 15x16 pixel image at scale of 2.
Add a small sanity check for this case.
Not updating shadow size unconditionally would lead to shadow size not
being set on map, which would lead mutter to think that we are a Window
without extents and then become confused when we suddenly set some.
Make sure that doesn't happen by always having shadows set on map, just
like GTK3.
Fixes#4136
