Expose information about if an event is handled to the backends.
This will allow a backend to deal with unhandled events, such as
macOS' default key bindings.
It started out as busywork, but it does many separate things. If I could
start over, I'd take them apart into multiple commits:
1. Remove G_ENABLE_DEBUG around GDK_DEBUG_*() calls
This is not needed at all, the calls themselves take care of it.
2. Remove G_ENABLE_DEBUG around profiling code
This now enables profiling support in release builds.
3. Stop poking _gdk_debug_flags and use GDK_DEBUG_CHECK()
This was old code that was never updated.
4. Make !G_ENABLE_DEBUG turn off GDK_DEBUG_CHECK()
The code used to
#define GDK_DEBUG_CHECK(...) false
#define GDK_DEBUG(...)
which would compile away all the code inside those macros. This
means a lot of variable definitions and debug utility functions
would suddenly no longer be used and cause compiler errors.
this is to prevent gdk from causing a segfault, when getting event axes
for events that don't have them (i.e. attempting to get pressure from a
mice input device).
The X11 backend can mark modifiers like Shift as consumed even if they
aren't actually active, which seems to be something to do with making
shortcuts like `<Control><Shift>plus` and `<Control>plus` work as
intended regardless of whether the plus symbol is obtained by pressing
Shift and a key (like `+/=` on American, British or French keyboards)
or not (like `*/+` on German keyboards).
However, this can go badly wrong when the modifier is *not* pressed.
For example, terminals normally have separate bindings for `<Control>c`
(send SIGINT) and `<Control><Shift>c` (copy). If we disregard the
consumed modifiers completely, when the X11 backend marks Shift as
consumed, pressing Ctrl+c would send SIGINT *and* copy to the clipboard,
which is not what was intended.
By masking out the members of `consumed` that are not in `state`, we
get the same interpretation for X11 and Wayland, and ensure that
keyboard shortcuts that explicitly mention Shift can only be triggered
while holding Shift. It continues to be possible to trigger keyboard
shortcuts that do not explicitly mention Shift (such as `<Control>plus`)
while holding Shift, if the backend reports Shift as having been
consumed in order to generate the plus keysym.
Resolves: https://gitlab.gnome.org/GNOME/gtk/-/issues/5095
Bug-Debian: https://bugs.debian.org/1016927
Signed-off-by: Simon McVittie <smcv@debian.org>
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.
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.
Since GdkTimeCoord stores only axis values, prior to this change,
if a device didn't report GDK_AXIS_X or GDK_AXIS_Y, the history
attached to merged motion events wouldn't contain any positional
information.
Commit 6012276093 already addressed
this issue for devices without tools by storing the event position
in GdkTimeCoord using GDK_AXIS_X and GDK_AXIS_Y and augmenting the
GdkTimeCoord's axis bitmask accordingly.
This change generalizes that workaround to all devices. Note that
if a device DOES report values for GDK_AXIS_X and GDK_AXIS_Y, those
values won't be overwritten.
Closes#4809
Add a new GdkScrollUnit enum that represent the
unit of scroll deltas provided by GdkScrollEvent.
The unit is accessible through
gdk_scroll_event_get_unit().
This change is done for 2 reasons:
- The logic to request this phase when compressing scroll events is
slightly broken. If there are multiple scroll events that are
coalesced into one, the surface frame clock will not get this request.
The worst case is having >= 2 scroll events on every frame, as the
compressed event will be left in the queue, and be further compressed
on future events.
- Even scroll events aside, this phase is requested in oddly specific
places that are not enough to cover all events, others do rely on
unrelated GdkFrameClock activity that happens to flush the events
as well.
Unify this phase request so it explicitly happens on the arrival of any
event. This ensures that events (compressed or not) will be handled
promptly after arrival.
It makes sense to connect the begin/update/end events
for touchpad swipes and pinches in a sequence. This
commit adds the plumbing for it, but not backends
are setting sequences yet.
Remove a boatload of "or %NULL" from nullable parameters
and return values. gi-docgen generates suitable text from
the annotation that we don't need to duplicate.
This adds a few missing nullable annotations too.
GTK traditionally lets you activate keyboard shortcuts
even if they are for a non-active layout. But it is meant
to only activate with a keysym from a non-active layout
when that symbol is not present in the current layout.
That last condition was lost when key event handling
was redone for GTK4. Bring it back.
100% symbol docs coverage.
833 symbols documented.
0 symbols incomplete.
0 not documented.
What's left are just type system macros and windowing system opaque
structures.
This removes the GDK_CONFIGURE event and all related functions and data
types; it includes untested changes to the MacOSX, Win32 and Broadway
backends.
The use of volatile was incorrect in GLib and has been that way for
a long time. Recently however that has changed, and this makes GTK
follow suit to avoid using volatile in the type registration.
See also: https://gitlab.gnome.org/GNOME/glib/-/merge_requests/1719
Combined with the above merge request for GLib, this fixes a large
number of compilation warnings when using Clang.
The current code was marking queued events as flushed,
but left them in the queue. That doesn't make sense to
me - we should deliver all events we have before we
reach the paint phase of the frame cycle.
No users of gdk_display_peek_event, gdk_display_has_pending
_gdk_display_event_data_copy or _gdk_display_event_data_free,
so drop all of these, and related vfuncs.
Make GdkEvents hold a single GdkDevice. This device is closer to
the logical device conceptually, although it must be sufficient for
device checks (i.e. GdkInputSource), which makes it similar to the
physical devices.
Make the logical devices have a more accurate GdkInputSource where
needed, and conflate the event devices altogether.
