diff options
| author | srdusr <[email protected]> | 2025-02-13 01:14:00 +0200 |
|---|---|---|
| committer | srdusr <[email protected]> | 2025-02-13 01:14:00 +0200 |
| commit | ed0b8ecf6c08d920ffd1b52c9dc6a24a436ce977 (patch) | |
| tree | 0841a1a8d13a5f36a89f611dde27e6cb9db31c5b /crates/core/src/manager | |
| parent | b1d69a552cdcc7370c4befd42ef2111c8b367c46 (diff) | |
| download | srdwm-ed0b8ecf6c08d920ffd1b52c9dc6a24a436ce977.tar.gz srdwm-ed0b8ecf6c08d920ffd1b52c9dc6a24a436ce977.zip | |
Implement the Wayland implicit pointer grab
Every pointer motion event re-ran the same popup/layer/content hit-test
from scratch and delivered focus to whatever it found right now - there
was no notion of "a button is held, keep delivering to the surface that
received the press" at all, which is standard, expected Wayland
compositor behavior (every real compositor does this; it's how dragging,
text selection, and scrollbar-thumb dragging all stay coherent even when
the pointer briefly leaves the widget's bounds mid-gesture).
Without it, a real human's hand drifting even slightly outside the
pressed surface mid-drag - trivially easy during a fast, non-perfectly-
straight mouse motion - sent that client an unrequested `leave` event in
the middle of its own gesture. GTK's drag recognizers (a GtkHeaderBar's
move-the-window gesture, concretely) treat a mid-gesture leave as "this
isn't coherent, abort," which reads as "dragging this window by its
title bar does nothing at all" - live-reproduced this work on Nemo,
and consistent with move_request never having fired once all session
despite real attempts.
pointer_button_grab captures the (surface, origin) resolved on a button
press once the held-button count goes from 0 to 1, and every event under
the grab - motion or button, this press's or a later one overlapping
it - is delivered there instead of wherever a fresh hit-test lands,
until every held button is back up.
Diffstat (limited to 'crates/core/src/manager')
0 files changed, 0 insertions, 0 deletions