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
There were several mistakes here.
The width of subtextures was set to the width of
the main texture, the data size wasn't properly
calculated, and the preconditions were inverted.
Yay us!
Those property features don't seem to be in use anywhere.
They are redundant since the docs cover the same information
and more. They also created unnecessary translation work.
Closes#4904
Previously, there was an issue with glitching after showing/hiding a
popover that was not also destroyed. This was due to the popover having
an update_freeze_count of zero after hiding the surface.
That resulted in it's toplevel continuously dropping frames such as during
high-frame-rate scrolling in textviews. This problem is much more visible
on high-frame-rate displays such as 120hz/144hz.
With this commit, we freeze the frame clock of the popup until it is
mapped again.
