Repository navigation
feat(widget): dockear al monitor principal por defecto y avisar si el widget queda en otro display #113
Description
Pre-flight checks
- Busqué issues existentes y no encontré duplicados.
- Entiendo que esta propuesta requiere revisión de producto antes de implementarse.
Problem to solve
Descubierto durante el port a macOS (#69, verificación M3): con dockMonitor: null, el frontend resuelve la posición del widget con currentMonitor() (el monitor "actual", que depende de dónde esté el cursor/foco) en vez del monitor principal. En un setup multi-display el widget puede dockearse al borde de un monitor externo — incluso uno ubicado fuera de la vista natural del usuario (arriba del principal) — y como la tira en modo peek es una franja fina (~210 px), el widget parece "desaparecido".
Reproducción real: macOS multi-display (Retina principal + externos, uno de 3008×1692 arriba del principal), dockEdge: "top", dockOffset: 0.53, dockMonitor: null → la ventana del widget quedó en y = -1692 (borde superior del externo). En Windows no se nota porque la taskbar vive en el display principal; el dockeo actual nunca tuvo este caso a la vista.
Proposed solution
Dos cambios de comportamiento (ambos acotados al frontend/Rust de geometría ya existente):
- Con
dockMonitor: null, resolver la geometría contra el monitor principal (primaryMonitor()) por defecto, no contracurrentMonitor(). El "actual" queda solo cuando el usuario fijó explícitamente un monitor en Ajustes. - Al mostrar la tira en un display no principal, emitir una notificación/aviso breve ("Quorb está en el monitor X") o re-dockear al principal si el elegido no está visible.
Affected area
Application behavior
Scope and non-goals
Incluye: default de monitor para el dockeo, aviso/redock de seguridad. No incluye: soporte de widget simultáneo en varios displays, gestión de perfiles por display, cambios de estilo del widget, ni la validación del port macOS (eso sigue en #69 / PR #112).
Alternatives considered
- Dejar el comportamiento actual y solo documentarlo: descartado, el "widget invisible" es una mala primera experiencia en multi-display.
- Recordar el último monitor por coordenadas de ventana en vez de por nombre: frágil si cambia la disposición de displays; el nombre + fallback a principal es más estable.
Activity
egdev6 commentedon Oct 14, 2026
@barbatdev, gracias por la reproducción concreta. El problema está respaldado por
src/Widget.tsx:55–62:resolveGeopriorizacurrentMonitor()sobreprimaryMonitor()cuando no hay monitor fijado, y también cuando el nombre guardado ya no está disponible. Una precisión para el diagnóstico:currentMonitor()devuelve el monitor donde está la ventana, no el del cursor/foco; las coordenadas negativas son válidas en una disposición con pantallas arriba o a la izquierda.Propongo acotar los criterios antes de implementar:
dockMonitor: null: usar el principal por defecto.Separaría el fix del default de la política opcional de avisos/recuperación. “No visible” necesita una definición comprobable: una pantalla desconectada no es lo mismo que una conectada que el usuario no está mirando. Esta revisión no implica todavía aprobación de producto para implementar ni cierra la validación macOS de #69/#112; he contrastado el código y el contrato de la API, sin reproducir personalmente el escenario multipantalla.
barbatdev commentedon Oct 14, 2026
Gracias por la precisión — acepto la corrección del diagnóstico:
currentMonitor()devuelve el monitor donde está la ventana, no el del cursor/foco, y las coordenadas negativas son válidas en disposiciones con pantallas arriba/izquierda (en mi máquina el-1692era exactamente eso).Los criterios acotados me parecen bien y los acepto como base de diseño:
dockMonitor: null→ principal por defecto.Y coincido en separar el fix del default (esta issue, comportamiento) de la política opcional de avisos (separate decision), y en que «no visible» necesita definición comprobable — «monitor no disponible» es el criterio operativo, no «el usuario no lo está mirando».
Quedo a la espera de la aprobación de producto antes de implementar; cuando la haya, propongo entregarlo como PR acotada separada de #112 con tests de geometría deterministas sobre
resolveGeo.