sl0ptty: the split guide arms on dwell, not on contact

A pointer crossing a border on its way somewhere else made the screen flash.
The guide now waits for the pointer to rest (hover_delay_ms, 250ms by default,
0 to disable).

The timer is on pointer stillness rather than on the hovered target, which is
what makes a sweep across three borders arm none of them: every motion event
that changes the position restarts the clock, so only stopping counts.

Holding the button on a border skips the wait, because that is intent rather
than passage.

This needs the loop to wake when nothing has happened — a pointer that is
deliberately not moving generates no events to repaint on — which is the same
self-scheduled repaint toasts already needed, so app_next_deadline_ms grew a
second reason rather than the loop growing a second mechanism.

Four older guide tests waited 60ms and now wait for the dwell; they were
asserting on contact because contact was all there was.

398 checks green.

1 files changed, 5 insertions, 4 deletions

diff --git a/src/server.c b/src/server.c
index 94f55ed..1579281 100644
--- a/src/server.c
+++ b/src/server.c
@@ -217,10 +217,11 @@ int server_run(const char *name, const char *const argv[], uint16_t cols,
       int t = due <= 0 ? 0 : (int)due;
       if (timeout < 0 || t < timeout) timeout = t;
     }
-    /* a toast expires on its own, so the loop has to wake for it */
-    int toast_due = app_next_deadline_ms(s.app);
-    if (toast_due >= 0 && (timeout < 0 || toast_due < timeout)) {
-      timeout = toast_due;
+    /* some things happen without an event: a toast expiring, a hover guide
+     * arming under a pointer that is deliberately not moving */
+    int self_due = app_next_deadline_ms(s.app);
+    if (self_due >= 0 && (timeout < 0 || self_due < timeout)) {
+      timeout = self_due;
       pending_paint = true;
     }