diff options
| author | srdusr <[email protected]> | 2026-05-11 16:44:00 +0200 |
|---|---|---|
| committer | srdusr <[email protected]> | 2026-05-11 16:44:00 +0200 |
| commit | caec1e7c355bbe6437afe87cd3dab6b64fb91e0a (patch) | |
| tree | 5ecab25d2ebc36949ac4129b35e35334a575d563 /crates/wayland/src/desktop_icons.rs | |
| parent | baabd91411dacd179c690f724b6cbfe6270cb131 (diff) | |
| download | srdwm-caec1e7c355bbe6437afe87cd3dab6b64fb91e0a.tar.gz srdwm-caec1e7c355bbe6437afe87cd3dab6b64fb91e0a.zip | |
Three live bug reports after a restart: icon drag, lock cursor, lock box
All three reported directly after the owner restarted into today's build.
Desktop icons could not be dragged at all in single-click mode. The press
handler opened the icon immediately when general.desktop_icon_single_click
was on, so the branch that starts a drag was unreachable and an icon could
never be moved. Deciding activation on press cannot distinguish a click from
the first instant of a drag. Every press on an icon now starts a potential
drag and release decides which it was, using a 4px movement threshold that
latches once exceeded. Double-click mode goes through the same path, so both
modes now drag identically.
The lock screen drew no cursor. The cursor push in the udev render loop sits
inside `if !locked`, and a locked head renders only the lock element list, so
nothing drew a pointer - and on a bare TTY nothing else does. The on-screen
keyboard's clicks were being handled correctly the whole time
(native_lock_click); they simply could not be aimed. The pointer is now
prepended to the lock element list, above the UI it is used to click.
The password field's opaque panel is gone. New LockConfig::box_opacity,
default 0.0: no fill, no border, no rounded rectangle, just the dots and
status text over the blurred background. Raising it restores the panel at
that opacity for anyone who wants a solid field. Drawing text on a
transparent surface needed a new blit_glyph_over: the existing blit_glyph
blends against one flat opaque colour and writes alpha 255, which would have
turned every glyph into a block of the assumed background - the same box
with its middle removed.
VERIFICATION STATUS, stated plainly: all three are code-complete and the
suite passes, but none is confirmed on screen. The nested backend's capture
pass does not draw the desktop icon grid (a gap already recorded in
winit/capture.rs), so the icon drag cannot be checked by screenshot there,
and aiming blind is what this project's own rules forbid. The two lock
changes were not visually checked either.
515 tests pass, clippy clean.
Diffstat (limited to 'crates/wayland/src/desktop_icons.rs')
| -rw-r--r-- | crates/wayland/src/desktop_icons.rs | 24 |
1 files changed, 24 insertions, 0 deletions
diff --git a/crates/wayland/src/desktop_icons.rs b/crates/wayland/src/desktop_icons.rs index c3b573a..b556bef 100644 --- a/crates/wayland/src/desktop_icons.rs +++ b/crates/wayland/src/desktop_icons.rs @@ -79,8 +79,32 @@ pub(crate) struct DesktopIconDrag { /// `(icon id, fixed offset from primary's own top-left at drag /// start)` - primary included at offset `(0, 0)`. pub(crate) members: Vec<(String, (i32, i32))>, + /// The icon the press actually landed on, and where the pointer was. + /// Release compares against this to decide whether the gesture was a + /// click or a drag - see `DRAG_THRESHOLD`. + pub(crate) pressed: (String, (i32, i32)), + /// Set once the pointer leaves `DRAG_THRESHOLD` of `pressed`. A press + /// that never does is a click, not a move. + pub(crate) moved: bool, } +/// How far the pointer must travel from the press point before a desktop +/// icon gesture counts as a drag rather than a click, in logical pixels. +/// +/// Every press on an icon now starts a *potential* drag, and release +/// decides which it was. Without that, single-click mode (`general. +/// desktop_icon_single_click`) made dragging impossible: the press opened +/// the icon immediately, so the drag branch was unreachable and an icon +/// could never be moved at all. Reported live as "i can't move the desktop +/// icons anymore since making it single click ... impossible to hold and +/// drag move desktop icons". +/// +/// Small, because the cost is asymmetric: too large and a genuine short +/// drag is swallowed as a click that opens something the user did not want +/// opened; too small only means an unusually shaky click moves an icon a +/// cell, which is visible and trivially undone. +pub(crate) const DRAG_THRESHOLD: i32 = 4; + pub(crate) struct DesktopIcons { /// Top-left of the grid's own `(0, 0)` cell, in global space, one per /// participating monitor - each monitor's own usable-area origin plus |