Repository navigation
bug(linux): degradaciones informadas como éxito o con indicaciones que no resuelven (atajos, bandeja, auto-hide) #181
Description
Pre-flight checks
- I searched existing issues and found no duplicate.
- I understand that this report enters review before implementation.
What happened?
Tres superficies muestran el mismo patrón en Ubuntu 26.04 + GNOME Wayland: la
app no informa que algo falló, o informa una indicación que no puede
resolverse. Es la clase de fallo que #107 prohíbe explícitamente
(«los fallos no se presentan como activación exitosa»).
1. Atajos globales: silencio total.
En «Ajustes › Atajos» cambié el atajo de mostrar/ocultar la tira y lo ejecuté:
sin efecto y sin mensaje de ningún tipo. Volví al valor anterior: idéntico.
Mientras tanto config.json persiste shortcuts.enabled: true con
toggle: "Ctrl+Shift+U", es decir la configuración afirma que los atajos están
activos. En el log de la app aparece únicamente
Couldn't get key from code: AudioVolumeUp (x2), que viene de
tao-0.37.1 src/platform_impl/linux/keyboard.rs:248 y no es un reporte de
fallo de registro. En Wayland el portal de atajos puede denegar el registro;
que lo deniegue es un límite aceptable, que pase en silencio no.
2. Bandeja: instrucción incumplible.
«Sesión de escritorio» indica: «GNOME oculta la bandeja por defecto: instala la
extensión «AppIndicator»». La extensión ya está instalada
([email protected]), y el icono no aparece porque la sesión no
tiene ningún host StatusNotifier (verificado por D-Bus: no existe
org.kde.StatusNotifierWatcher; el dock estándar fue reemplazado por otra
extensión). Quorb crea el indicador (se ve en el log:
libayatana-appindicator se inicializa) pero no hay dónde mostrarlo. El aviso
debe verificar la existencia del host, no solo sugerir instalar una extensión
que ya está presente.
3. «Ocultar sola» recomendada pero incumplible.
El mismo bloque recomienda «si la tira se oculta tras ventanas, usa
Auto-hide». Con autoHide: true ya activo no ocurre nada: no hay franja en el
borde que retraer (por la causa de posicionamiento descrita en el otro
reporte) y al revelarse la ventana queda por debajo de las demás. La
recomendación no cumple lo que promete en este compositor.
Steps to reproduce
- Ejecutar Quorb en Ubuntu 26.04 + GNOME Wayland (
npm run app:dev). - Atajos: Ajustes › Atajos, cambiar el atajo de la tira, pulsarlo. Observar
ausencia total de efecto y de mensaje. Inspeccionarconfig.json
(shortcuts.enabledsigue entrue). - Bandeja: verificar en Ajustes el consejo de «AppIndicator», comprobar con
gnome-extensions listque la extensión ya está instalada y con ungdbus
call aListNamesque no hay ningúnStatusNotifierWatcher. - Auto-hide: con «Ocultar sola» activa y Firefox encima de la tira, acercar el
ratón al borde: no se revela ninguna franja y la tira sigue tapada.
Expected behavior
- Si el registro de un atajo falla o no está disponible en la sesión, Ajustes ›
Atajos muestra un estado de error accionable yshortcuts.enabledno queda
entrue. - El consejo de bandeja se emite solo cuando realmente falta la extensión; si
la extensión existe y no hay hostStatusNotifier, informa esa causa. - Las recomendaciones de mitigación se ofrecen solo si pueden surtir efecto en
el compositor detectado, o declaran su alcance real.
Environment
OS: Ubuntu 26.04.1 LTS (Resolute Raccoon), x86_64
Session: XDG_SESSION_TYPE=wayland, XDG_CURRENT_DESKTOP=ubuntu:GNOME (Mutter)
Tray host: sin org.kde.StatusNotifierWatcher (D-Bus ListNames verificado)
Extensions: [email protected] instalada, dock reemplazado por el del usuario
Quorb: main @ 404dca5 (post #169), ejecutado con `npm run app:dev`
Config: shortcuts.enabled=true, shortcuts.toggle=Ctrl+Shift+U, autoHide=trueAffected area
Application behavior
Agent or client (for MCP or headless incidents)
No response
Shell (for MCP or headless incidents)
No response
Anexo: límites y contexto
- Medido en GNOME/Mutter; KDE no se probó en esta sesión.
- El sonido de alertas no está probado (requiere personalización con vídeo):
queda fuera de este reporte, declarado como no cubierto. - Relación con feat(linux): hacer funcional el escritorio y widget nativos #107: esta clase es el criterio 4 de aceptación de esa issue
(«notificaciones, atajos y autostart se verifican o se declaran limitaciones
claras; fallos no se presentan como activación exitosa»). Publicar aquí
permite que feat(linux): hacer funcional el escritorio y widget nativos #107 se cierre con evidencia por criterio y este trabajo quede
con su propio ciclo de revisión.
Activity
egdev6 commentedon Oct 25, 2026
@SrStamm gracias por el reporte — el patrón que describes (fallos que no se presentan como fallos) es exactamente lo que el criterio 4 de #107 prohíbe, y lo documentas con la evidencia justa. Triaje hecho:
type:bug+status:approved— los tres puntos son accionables sin más decisiones de producto.Verificación y plan por punto
1 · Atajos: silencio total ✅ real, con un matiz que tu reporte intuye. El código sí tiene canal de errores:
apply_shortcuts()(lib.rs:84) captura fallos deregister()y los muestra como avisos rojos en Ajustes › Atajos (víashortcut_errors). Que no vieras nada apunta a la peor variante:register()devolvióOk(GTK registró un acelerador local que no es global) — «éxito» sin funcionalidad, y por esoshortcuts.enabledqueda entrue. La nota dewm_compat.rs(«el error se muestra en Ajustes › Atajos») queda en evidencia: asume que denegación = error, pero existe el camino sin denegación y sin efecto.Fix planificado: (a) probe de lab que determine qué ocurre exactamente bajo GNOME Wayland (¿portal
GlobalShortcuts? ¿acelerador local silencioso?) — mismo método F1–F14 del lab de #90; (b) diferenciar «registrado» de «funcional»: sin host del portal o sin X11, el estado va a «limitado» con mensaje accionable y no se afirma activación; (c) decidir qué haceshortcuts.enableden ese caso (mantener la intención del usuario pero reflejar el estado real, no mentir).2 · Bandeja: consejo incumplible ✅ verificado en código:
wm_compat.rs:250emite el texto estático «instala la extensión «AppIndicator»» para todo GNOME, sin comprobar el host. Tu verificación por D-Bus (extensión instalada, sinorg.kde.StatusNotifierWatcher) es el caso que el aviso no contempla.Fix planificado: sondear
org.kde.StatusNotifierWatcherenListNamesantes de emitir el consejo, con tres mensajes según la causa real: extensión ausente / extensión presente sin host / host presente (y entonces el problema es otro). Sondeo barato, ya tenemos el patrón de sondas enwm_compat.rs.3 · Auto-hide recomendado sin efecto ✅ — consecuencia directa de #180 (sin posicionamiento no hay franja que retraer ni ventana sobre la que revelar). Fix: condicionar ese consejo al estado real del posicionamiento (el gate de #180 o el modo X11). Va en el mismo ciclo que #180, no antes.
Orden
Si te apetece tomar los puntos 1–2 como tu primer PR en el proyecto, dime y te abro el ODD correspondiente — el flujo de siempre: plan en la issue, revisión, y a implementar.
SrStamm commentedon Oct 25, 2026
¡Hola! La verdad es que me gustaría contribuir con esto. Confirmo: tomo los puntos 1–2 como mi primer PR.
Como no tengo permiso de escritura en el repo, ¿te puedo pedir que me abras el ODD correspondiente y me asignes la issue (o me digas cómo lo manejás vos)? Quedo atento al flujo que uses para el ODD y sigo el plan de siempre: plan en la issue, revisión y a implementar.
El punto 3 lo dejo fuera de mi alcance, en el ciclo de #180 como marcaste en el triaje.
egdev6 commentedon Oct 25, 2026
@SrStamm por supuesto! todo tuyo! dale candela...te los asigno <3
egdev6 commentedon Oct 25, 2026
Con ODD las issues sirven como punto de definición. El repo lleva una skill que te ayudará a entender el flujo de github. Pregunta a tu orchestrator. Cualquier duda en la comunidad tenemos foros dedicados al proyecto. Aquí tienes todas mis redes y enlace al dicord si gustas :D
https://www.egdev.es
SrStamm commentedon Oct 25, 2026
ODD — Plan de implementación (puntos 1 y 2)
Tomo los puntos 1–2 según el triaje (el punto 3 queda en el ciclo de #180).
Lab/probe del punto 1 — causa raíz confirmada
tauri-plugin-global-shortcut2.4.0 depende deglobal-hotkey0.8.0, que en Linux solo compila el backend X11 (src/platform_impl/mod.rsmapea todo Linux ax11/mod.rs); no existe backend Wayland en la crate.register()es unXGrabKeypasivo sobre la root de XWayland. Con foco en ventanas Wayland, Mutter no entrega las teclas →register()devuelveOksin efecto global. Por eso no aparece ningún error en Ajustes › Atajos yshortcuts.enabledqueda entrue: «éxito» sin funcionalidad, exactamente el patrón reportado.org.freedesktop.portal.GlobalShortcutsexiste (xdg-desktop-portal-gnome), pero el plugin no lo usa. Migrar al portal queda como mejora posterior, fuera de este alcance.Punto 1 — atajos: diferenciar «registrado» de «funcional»
apply_shortcuts(src-tauri/src/lib.rs): si la sesión es Wayland, los atajos registrados vía X11/XWayland pasan a un estado «limitado» con mensaje accionable, en un canal de avisos junto a los errores existentes (el registro X11 se conserva como best-effort).shortcuts.enabledconserva la intención del usuario; el estado real se refleja en la UI, no en la config.Punto 2 — bandeja: consejo según la causa real
org.kde.StatusNotifierWatcherenListNames(D-Bus) y la extensión AppIndicator antes de emitir el consejo (wm_compat.rs).surfaces_for.Verificación prevista
npm test,npm run typecheck,cargo test+ comprobación en la sesión GNOME Wayland real.egdev6 commentedon Oct 25, 2026
@SrStamm gracias por el probe y por separar la presencia del portal de su uso real por el plugin. Ese hallazgo corrige nuestra hipótesis anterior: que exista
GlobalShortcutsno hace que un backend basado enXGrabKeylo utilice.Plan aprobado con dos ajustes al contrato antes de implementar. La explicación del backend está bien detallada; este visto bueno es sobre el plan, no una reproducción independiente de tu lab ni una revisión de las fuentes de esas dependencias.
Punto 1 — conforme ✅
shortcuts.enabledcomo intención del usuario y mostrar el estado efectivo por separado.register()devuelvaOk.Ajuste 1 — bandeja: no confundir observaciones con causas
La ausencia de
org.kde.StatusNotifierWatcherno demuestra que falte una extensión, y una extensión instalada tampoco demuestra que esté habilitada o funcionando.El estado principal debe distinguir host presente / host ausente / sondeo fallido o desconocido. La información de la extensión es complementaria, con estado instalado/habilitado/desconocido cuando pueda determinarse de forma fiable. Si no hay host, explicar que no se detectó dónde mostrar el indicador; no recomendar reinstalar una extensión que ya existe. Si hay host, no afirmar que el icono es visible sin comprobarlo: solo se acredita la disponibilidad del host.
Ajuste 2 — sondas acotadas y controles negativos
Las consultas a D-Bus y al estado de extensiones deben tener timeout, no bloquear la UI y degradar a «desconocido» cuando fallen. No convertir un error de diagnóstico en «extensión ausente».
Añadir tests deterministas para:
Ok, pero aviso de alcance limitado.Con esos ajustes, adelante con la implementación de los puntos 1–2 y la verificación prevista, incluida la sesión GNOME Wayland real. El punto 3 sigue coordinado con #180, fuera de esta entrega. Gracias por mantener el alcance acotado y el diagnóstico honesto.
SrStamm commentedon Oct 25, 2026
Evidencia de implementación y verificación (puntos 1–2)
Implementado en
SrStamm/quorbramafix/181-wayland-degradation-reporting; PR a continuación con el detalle.Punto 1 — atajos (conforme, con la matriz de tests pedida)
compute_shortcuts(lib.rs): cubre los caminos que antes quedaban dentro deapply_shortcuts(que necesitaAppHandley no es testeable).Ok→ aviso de capacidad; X11+Ok→ nada; deshabilitado → sin falso aviso; error real de registro → error conservado, sin aviso de capacidad; combinación no válida → error, no aviso.eg-notice--warningconrole="status", distinguidos de los errores rojos (role="alert"); badge de «Atajos» cuenta ambos;shortcuts.enabledintacto como intención.Punto 2 — bandeja (ajustes 1 y 2 aplicados)
surfaces_for: estado primario del host (org.kde.StatusNotifierWatchersondeado víagdbus ListNames) y extensión AppIndicator complementaria víagnome-extensions list(salida por UUIDs, independiente del locale —infoestá traducido y no es parseable de forma fiable).#[ignore](mismo patrón que el smoke de Secret Service).Comprobación en la sesión real del reporte (Ubuntu 26.04 + GNOME Wayland)
cargo test --lib -- --ignored --nocapture: host ausente + extensión instalada pero deshabilitada (el dock fue reemplazado por aztaskbar) → nota: «No se detectó ningún host StatusNotifier en la sesión: no hay dónde mostrar el icono. La extensión «AppIndicator» está instalada pero deshabilitada: habilitala.»gnome-extensions enable [email protected]+ reinicio → la fila pasa a «sin límites conocidos: Host StatusNotifier detectado y extensión «AppIndicator» habilitada: hay dónde mostrar el icono. Si no aparece, la causa está en la barra, no en la sesión.» Sin afirmar visibilidad.Checks
npm test: 676 vitest + 225 node --test, verde.npm run typecheck: verde.cargo test --locked: 280 passed, 0 failed, 2 ignored (smokes reales).node scripts/i18n-inventory.mjs: regenerado y commiteado (+12 strings de Rust).docs(i18n): regenerar inventario i18n tras egdev6#181
docs(odd): cierre de egdev6#181 — PR abierta y evidencia registrada
docs(odd): registrar apertura de PR egdev6#183 en el doc de tareas (e…
fix(linux): la presencia del host StatusNotifier prevalece sobre la e…
fix(linux): sondeas de bandeja con runner acotado compartido (egdev6#181
fix(linux): get_wm_info async con sondas en spawn_blocking (egdev6#181,…
docs(odd): cierre de los tres cambios requeridos en la revisión de eg…
docs(odd): evidencia publicada en PR egdev6#183 y push registrado (eg…
fix(linux): degradaciones informadas como éxito o con consejos incump…
Merge branch 'fork/main' into w2-fase-a