Try to get a native file:// URI instead of any other GVFS
scheme, for interoperability with apps only handling file:// URIs.
This is what GTK3 Nautilus and Thunar do, so apps should be tuned
for this behavior.
See also https://bugzilla.xfce.org/show_bug.cgi?id=13845Fixes: #5422
GDK_TOUCH_END deserves the same treatment than GDK_BUTTON_RELEASE, since it's
subject to the same circumstances (popping up a menu on long press would be
immediately dismissed on release if we handled them there). Ideally, we would
want to match releases that we obtained a press for while grabbed, but as
the popup is also dismissed on GDK_BUTTON_PRESS/GDK_TOUCH_BEGIN, there's no
use for this tracking.
And GDK_TOUCH_CANCEL sounds weird as a reason to dismiss popups, just like
crossing events would.
Related: https://gitlab.gnome.org/GNOME/mutter/-/issues/2512
clang complained that we may end up jumping
to the cleanup code without initializing data
in the jpeg code. Always initialize data to
NULL to prevent that eventuality.
This is largely adapted from commit 83027c68f1 ("11: Implement
inhibit_system_shortcuts API"), with similar rationale:
To implement the inhibit_system_shortcuts API on X11, we emulate the
same behavior using grabs on the keyboard.
To avoid keeping active grabs on the keyboard that would affect
other X11 applications even when the surface isn't focused, the X11
implementation takes care of releasing the grabs as soon as the
toplevel loses focus.
Note that Windows has low-level keyboard hooks that could help achieve
the expected behaviour. This is implemented by spice-gtk & gtk-vnc for
example, but correctness isn't obvious. I left a TODO comment.
This patch helps implementing remote desktop widgets with GTK4, since
currently on win32 backend Alt-Tab and such are always left to the
system unless there is keyboard grab (which can't be requested by the
client API anymore, afaict).
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
There's 2 things broken here:
- The mask was calculated on top of the GDK button (i.e. skipping
4-7 buttons), so GDK_BUTTON4_MASK and GDK_BUTTON5_MASK were not
assigned. This is now calculated on the (continuous) BTN_ evcodes
so it is guaranteed that the next 2 physical buttons (i.e.
back/forward) get these two places in the mask assigned.
- Furthermore, these buttons would be pushed to places in the
modifier mask that they didn't belong to. It is now checked hard
that only the first 5 buttons enable a modifier flag.
Overall, this ensures that no event masks with bonkers values are
forwarded, and that no stale implicit grabs are left after additional
buttons are pressed.
Closes: https://gitlab.gnome.org/GNOME/gtk/-/issues/5301
This makes GtkSettings values on X11 match what we get on
other backends.
Reporting size settings in logical pixels (i.e for scale
== 1) is useful for properly supporting mixed-DPI setups.
As X11 doesn't support mixed-DPI setups anyway, XSettings
doesn't bother providing logical values. Thus we scale
from physical to logical values ourselves.
Fixes https://gitlab.gnome.org/GNOME/gtk/-/issues/5223
Fixes https://gitlab.gnome.org/GNOME/gtk/-/issues/5230
When getting the serial for primary/clipboard selections we used a
function that largely relied on a GdkEvent being passed. We have
another available function that looks up the most recent serial
given the ongoing touch/tablet input as well.
This is the second best, compared to actually knowing the
input/device from the event that was received by the UI an triggered
the clipboard operation, and is already in use in other places
(e.g. window dragging). It is valid for these situations too.
Closes: https://gitlab.gnome.org/GNOME/gtk/-/issues/5250
Use newlines rather than spaces to separate file paths (or uri's)
when serializing text/plain files. There isn't a matching
deserializer, so we can do this in isolation. Newlines
seem to make more sense when pasting into a text editor etc.
Fixes: https://gitlab.gnome.org/GNOME/gtk/-/issues/5240
As documented on MSDN:
> Unlike the WM_LBUTTONUP, WM_MBUTTONUP, and WM_RBUTTONUP messages, an
> application should return TRUE from this message if it processes it.
