We don't need all of them, only the ones that contain public API. This
allows us to reduce the chance of a stray symbol getting incorrectly
added to the introspection data.
This removes the use of the context menu and shift group
intents in gdkevents.c. If it turns out to be important,
we need to introduce vfuncs for gdk_event_triggers_context_menu
and gdk_event_matches.
Add all of the keyboard translation results in the key event,
so we can translate the keyboard state at the time the event
is created, and avoid doing state translation at match time.
We actually need to carry two sets of translation results,
since we ignore CapsLock when matching accelerators, in
gdk_event_matches().
At the same time, drop the scancode field - it is only ever
set on win32, and is basically unused in GTK.
Update all callers.
The win32 backend is using GDK_MOD2_MASK for AltGr,
so define GDK_MOD2_MASK locally to keep this working,
but remove any mention of GDK_MOD3_MASK,...,GDK_MOD5_MASK.
With C compilers defaulting to -fcommon, this isn't an issue, but
upcoming compilers (GCC 10 and Clang 11) will default to -fno-common,
ending up with duplicate definitions of these variables.
With the removal of `gdk_seat_grab` we do not need to keep the
definitions of `GdkGrabStatus` and `GdkGrabOwnership` public.
Move those definitions to become internal only.
When we reconfigure, `configure_file()` is called again, and
`*.gresource.xml` files are regenerated, which causes many (all?)
binaries to be relinked. Now we only write those out if the contents
actually changed (or if the output didn't already exist).
This is exactly what Meson already does with `configure_file()` when
`command:` is not used.
While we're at it, also do the same for `gen-c-array.py` and
`gentypefuncs.py` for completeness. Now even if the input to those
changes, re-building of those custom targets may not result in
relinking if the outputted C files have the same contents.
When we `Alt+Tab` away from a GTK application, it loses keyboard focus.
If we don't clear the modifiers, events from other devices that we
receive while unfocused will assume `Alt` is still pressed. This results
in e.g. Firefox navigating through the history instead of scrolling the
page when using the mouse wheel on it.
We don't get any information about modifiers while we are missing
keyboard focus, so assuming no modifiers are active is the best we can
do.
The shell sends us a modifier update immediately before we regain
keyboard focus, so the state shouldn't get out of sync.
Fixes https://gitlab.gnome.org/GNOME/gtk/-/issues/2112
Win32 backend doesn't have support for inhibit shortcuts, yet it needs
support the standard set of GdkToplevel properties.
Add support for the "inhibit-list" object property to GdkToplevel on
win32.
Broadway doesn't have support for inhibit shortcuts, yet it needs to
support the standard set of GdkToplevel properties.
Add support for the "inhibit-list" object property to GdkToplevel on
Broadway.
On X11, there is no such equivalent to the inhibit shortcut protocol
found on Wayland.
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.
With the current implementation, we use a `wl_seat` as the key for our
internal has table where we store the Wayland shortcuts inhibitors.
There is however no technical reason for this, and we could use a
GdkSeat instead, which will ease the implementation of the GdkToplevel
shortcut inhibition API.
With the removal of grabs from the public API, we need a replacement API
to let applications bypass system keyboard shortcuts.
A typical use case for this API is remote desktop or virtual machine
viewers which need to inhibit the default system keyboard shortcuts so
that the remote session or virtual host gets those instead of the local
environment.
Close: https://gitlab.gnome.org/GNOME/gtk/issues/982
GTK defines various types that are meant to be derivable only within GTK
itself, and "final" from the perspective of consumers of the GTK API.
The existing macros defined by GObject, such as G_DECLARE_FINAL_TYPE and
G_DECLARE_DERIVABLE_TYPE, lack this functionality.
While we wait for GObject to get this kind of macro, we should define
our own.
