El sensor leia el teclado/mouse global con device_query para saber si hubo
entrada. En macOS eso exige el permiso de Accesibilidad y, como la app va sin
firma estable, macOS nunca lo retiene: el dialogo «... quiere controlar este
ordenador» reaparecia en cada arranque aunque ya se hubiera concedido.
Solo hace falta saber SI hubo entrada, no cual. macOS lo da con
CGEventSourceSecondsSinceLastEventType (segundos desde la ultima entrada HID),
de solo lectura y sin pedir ningun permiso. Windows/Linux siguen con
device_query (ahi no piden permiso), ahora como dependencia solo de esas
plataformas.
Verificado: cargo check OK (4.5s); prueba aislada de la API devuelve los
segundos de inactividad en vivo sin ningun dialogo de permiso.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Regla pedida por el usuario: si alguien mira un video en el navegador sin tocar
el mouse, no es que este quieto — esta viendo algo. Ahora el sensor lo cuenta
como tiempo de navegador en vez de inactividad.
- Excepcion del VIDEO (Windows): en el tick, si `ocioso` (3 min sin entrada)
PERO al frente hay un navegador (chrome/brave/edge/firefox/opera/vivaldi, se
excluye el host WebView2) Y el sistema esta sacando sonido, es un video
reproduciendose -> `viendo_video`. Se introduce `ocioso_efectivo = ocioso &&
!viendo_video`, y TODO (tramo de inactividad, bandeja, acumulacion de la
ventana) pasa a usar `ocioso_efectivo`. El bloque de navegador se acumula con
a=0 (segundos sin entrada real): presente, sin teclear. La bandeja lo dice
(«video en primer plano»).
- Deteccion de sonido: medidor de pico de la salida de audio por defecto
(WASAPI, IAudioMeterInformation via el crate `windows`, solo cfg(windows)).
No abre el navegador, no lee la pestaña, no graba nada — solo pregunta al SO
si hay sonido saliendo AHORA (pico > 0.01). Limite honesto documentado: un
video MUDO no se detecta. macOS: stub que devuelve false (no hay API publica
sencilla de nivel de audio; el equipo de edicion es Windows) -> comportamiento
identico al de siempre en Mac.
- La ventana al frente ahora se lee cada tic mientras se mide (antes solo con
actividad), porque hace falta para decidir la excepcion; se reutiliza esa
misma lectura para acumular, sin volver a preguntar al SO.
- COM se inicializa una vez al arrancar el hilo del sensor (cfg(windows)).
- El contrato con el servidor NO cambia: se sigue mandando {blocks, idles}, solo
que ahora hay menos idles y algun bloque de navegador cuando hay video. Nada
que tocar en labstream-os.
Verificado con `cargo check`: el reensamblado compila limpio en el host (macOS),
y el codigo WASAPI type-checkea contra el target x86_64-pc-windows-msvc (aislado
en un crate minimo, porque `ring` de la TLS de ureq no cross-compila su C a
Windows desde Mac — eso lo hace la CI). Falta la validacion final en una maquina
Windows real (no puedo reproducir audio de Windows aqui): probar que un video en
YouTube con el mouse quieto sale como navegador y no como inactividad.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Cada tramo sin ninguna entrada (mas alla del umbral de 3 min, que sigue contando como trabajo
igual que siempre) queda registrado como {desde, segundos} y viaja en el lote como `idles`,
aparte de los bloques. Sin app, sin titulo, sin contenido: la inactividad no tiene nada que
mirar. La bandeja lo dice: «inactivo (se anota aparte)».
Decisiones que importan, salidas de una revision adversaria previa (11 hallazgos, todos
atendidos):
- Tope de 4 h por tramo: una torre que nunca se suspende, bloqueada toda la noche, anotaba
«14 h inactivo» en el dia anterior. Mas de 4 h sin tocar el equipo es ausencia, no descanso;
pasado el tope no se reabre nada hasta que vuelva la entrada. El servidor ademas rechaza
cualquier tramo de mas de 6 h como red de seguridad.
- La suspension corta el tramo (la noche del portatil es una laguna, no un dato) y al
despertar el reloj queda EN el umbral: sin eso, los despertares automaticos de Windows a las
3 a. m. contaban hasta 3 min de trabajo fantasma y fabricaban jornadas de madrugada.
- El tramo en curso se persiste a disco (rastreador-encurso.json, un latido por minuto): un
apagado, el cierre de la app o la auto-actualizacion —que reinicia a todo el equipo a la
vez— lo cierran en su ultimo latido en vez de perderlo entero.
- La subida se acota a 12 lotes por ciclo y el tiempo de subida no cuenta como suspension:
al volver la red tras dias sin ella, los cientos de POST seguidos bloqueaban el hilo del
sensor y el siguiente tic diagnosticaba un «dormido» falso que cortaba el tramo abierto.
- La cola en disco lee el formato viejo (Vec<Vec<Bloque>>) ademas del nuevo: lo pendiente de
subir en la 1.8 no se pierde al actualizar.
- En pausa no se anota nada, y reanudar no retro-anota la pausa como ocio.
El servidor (labstream-os 453a640) ya acepta `idles` y enseña la columna «Inactivo» en las
jornadas de /rastreo; los sensores 1.8 siguen funcionando sin cambios.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Antes la pagina emitia el token a ciegas: en una app SIN sensor (anterior a la
1.8.0) nadie lo recogia y la pantalla cantaba "equipo vinculado" igual,
dejando un equipo registrado que jamas reporta.
- ls-tracker-token -> responde ls-tracker-listo (acuse). Sin acuse, la web
deshace el equipo que acaba de crear y avisa que hay que actualizar.
- ls-tracker-consulta -> responde ls-tracker-estado {vinculado, pausado,
version}, para no ofrecer vincular lo que ya esta vinculado y para poder
avisar de un clic a quien le falta.
Los dos emit salen en un hilo aparte, por el mismo motivo que los repintados
del menu: un listener puede correr en el hilo principal.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
`n.cola.drain(0..enviados.min(n.cola.len()))` no compila: el argumento pide
un prestamo inmutable de `n.cola` cuando ya esta prestado mutable, y a
traves del MutexGuard —un deref explicito, no un autoref— el two-phase
borrow no lo cubre (E0502, el UNICO error que encontro el CI en todo el
sensor).
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Sensor nuevo (src/tracker.rs): cada 5 s mira que app esta al frente y si
hubo entrada; con 3 minutos sin entrada deja de contar (ocio profundo, que
cubre tambien pantalla bloqueada y suspension). Acumula bloques {app,
titulo, segundos, segundos activos} y los sube cada 5 min a /api/tracker con
el token del equipo; sin red la cola persiste en disco y reintenta, y un 401
(token revocado desde Ajustes) descarta el token y vacia la cola.
Lo que NO hace, a proposito: no registra que teclas se pulsan —solo compara
una huella de posicion del raton y cuantas teclas hay presionadas—, no toma
pantallazos y no lista procesos de fondo. El estado vive VISIBLE en el menu
de la bandeja, con pausa de un toque.
Ojo al tocar el menu: set_text de Tauri despacha al hilo principal y bloquea
esperandolo, asi que llamarlo desde setup() —que corre en ese mismo hilo
antes de que el bucle de eventos atienda— colgaria la app al abrir. Por eso
los items nacen ya con su texto y todo repintado posterior sale de un hilo
secundario.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
