#147 Let the remote hide the mouse pointer

[Rob Swindell]

A full-screen graphical door has no way to ask SyncTERM to stop drawing the mouse pointer, so it sits on top of the image for the whole session. The door cannot paint over it, the window system draws it.

This applies whether or not the door uses the mouse. SyncRetro only reads the keyboard, and still gets an I-beam parked in the middle of the picture; a door that does use mouse motion gets an arrow over its scene. Either way it is noise.

setup_mouse_events() already picks ARROW or BAR from the active mouse mode, so a hidden state may fit as a third case there plus a CIOLIB_MOUSEPTR_NONE.

xterm's XTSMPOINTER (CSI > Ps p) is adjacent but governs hiding while typing, so motion brings the pointer back -- not what a door wants.

No opinion on the sequence. A CTDA capability, so a door can tell whether asking is worth anything, would be useful.

[Stephen James Hurd]

If a door does not steal the mouse, the mouse is for the user to use. It's an i-beam so the user can select text. If you hide the mouse, that would make it very difficult for the user to do what they want. The idea if my mouse pointer disappearing because I move it across a SyncTERM window sounds like something I would hate.

[Rob Swindell]

This is for the instance where the door steals the mouse but the pointer is not useful in the door (it's actually distracting and misleading).

[Rob Swindell]

Please disregard the SyncRetro example -- it is keyboard-only and never
enables mouse reporting, so it is not the case I mean.

The case is a full-screen first-person door that does take the mouse,
using movement to turn the view. It draws its own crosshair at the centre,
so the window system's pointer is a second cursor that means nothing; and
since a terminal cannot lock or warp the pointer, it drifts to wherever
the last turn left it and sits there. Not redundant -- misleading.

Findings from implementing against xterm and foot:

xterm has CSI > Ps p (XTSMPOINTER), setting pointerMode:

Ps = 0   never hide
Ps = 1   hide if mouse tracking is NOT enabled   (default)
Ps = 2   always hide, except when leaving the window
Ps = 3   always hide, even leaving/entering the window

Mode 1 is the interesting one: xterm declines to hide whenever the
application tracks the mouse, assuming it wants a pointer. Backwards for a
game, which tracks the mouse because it is a game. Modes 2 and 3 exist
so the application can say so -- xterm has had this argument and settled
it by letting the application ask.

But nothing switches the pointer off outright, xterm included. Every
pointerMode value is framed as hiding the pointer as the user types; the
mode number qualifies the window-crossing condition, not the typing
trigger. Confirmed live: with CSI > 3 p set, the pointer hides while
keys are held and returns the moment the mouse moves -- so in a game,
where the hand is on the mouse, it is visible nearly always.

foot gives the remote nothing; it can hide only from its own config
([mouse] hide-when-typing), which is the user's choice, not the
application's.

OSC 22 is not a way round it. xterm and foot both implement it for the
pointer shape, but no name hides -- foot documents empty/unknown as a
reset. I tried a crosshair and removed it the same day: two crosshairs is
worse than an arrow.

So CIOLIB_MOUSEPTR_NONE is not catching up with anyone -- it is a
capability no terminal currently has.

FWIW a door here already sends CSI > 3 p on entry and CSI > 1 p on
exit; SyncTERM ignores both, so a CTDA capability would not conflict with
doors already emitting the xterm sequence.