fix(linux): hacer que el widget sea visible en todos los escritorios virtuales (paridad con macOS)

Abierto
  • ¿Algo no está bien?
#227 1 comentario 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
2/5
Tiempo estimado
1-3 horas
Aptitud para principiantes
35/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
rust, tauri
Área
desktop

Línea de trabajo

The relevant gate is the #[cfg(target_os = "macos")] block around set_visible_on_all_workspaces(true) in src-tauri/src/lib.rs near line 1083. Read how the widget, detail and overlay windows are created, and check the tao Linux stick() path the issue cites, since it is a dependency and not in this repo. Before editing, get the maintainer's answer on whether this should be on by default or behind a setting, because the thread is still open. Done means the widget stays visible after switching workspaces on X11 or XWayland, with the failure logged and no change on macOS.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

Contexto y motivación

Quorb está concebido como una tira de estado y control continua. En Linux, al cambiar de escritorio virtual (workspaces en KDE Plasma, GNOME, etc.), la tira desaparece porque el gestor de ventanas la confina al escritorio donde se inició el proceso.

En #112 se incorporó set_visible_on_all_workspaces(true) en src-tauri/src/lib.rs:1083 con un gate #[cfg(target_os = "macos")] bajo la asunción de que en Linux bastaba con always_on_top («Windows/Linux have no Spaces and always-on-top already covers it»).

Sin embargo, en Linux (X11 / KDE / GNOME) always_on_top (_NET_WM_STATE_ABOVE) solo mantiene la ventana flotando por encima dentro del mismo escritorio virtual, pero no acompaña al usuario al cambiar de workspace. Para acompañar entre escritorios se requiere declarar la ventana como sticky (_NET_WM_STATE_STICKY / _NET_WM_DESKTOP = 0xFFFFFFFF).

Diagnóstico técnico

En el motor de ventanas de Quorb (tao 0.37.1), set_visible_on_all_workspaces(true) ya está plenamente implementado para Linux (tao/src/platform_impl/linux/window.rs:762 y event_loop.rs:424):

WindowRequest::SetVisibleOnAllWorkspaces(visible) => {
    if visible {
        window.stick();
    } else {
        window.unstick();
    }
}

La llamada a window.stick() de GTK envía al gestor de ventanas los mensajes EWMH oficiales para que la ventana se proyecte en todos los escritorios.

Alcance propuesto (Centrado en Linux)

Nos centramos exclusivamente en implementar y verificar esta paridad en Linux:

  1. Linux (X11 / XWayland):
    • Ampliar el gate en src-tauri/src/lib.rs: 
      #[cfg(any(target_os = "macos", target_os = "linux"))]
for label in [WIDGET, DETAIL, OVERLAY] {
    if let Some(w) = app.get_webview_window(label) {
        if let Err(e) = w.set_visible_on_all_workspaces(true) {
            eprintln!("No pude marcar «{label}» visible en todos los escritorios: {e}");
        }
    }
}
    • Otorga paridad inmediata con macOS sin dependencias nuevas ni cambios en la capa de frontend.
  2. Linux (Wayland nativo):
    • xdg-shell por diseño no ofrece a clientes regulares una petición para declararse sticky sin protocolos privilegiados de compositor (wlr-layer-shell). Con el camino X11/XWayland (GDK_BACKEND=x11), queda cubierto en el entorno operativo de Linux.
Pregunta para el mantenedor / Decisión de producto

¿Preferís que este comportamiento sea predeterminado e inherente al widget (igual que en macOS desde #112), o considerás necesario que esté sujeto a un interruptor en Ajustes (ej. Ajustes > Comportamiento > Mostrar en todos los escritorios virtuales)?

Abrimos el hilo para acordar la dirección antes de preparar la PR.

Lenguaje dominante
TypeScript
Estrellas
10
Forks
2
Merge medio
5 h 55 min
PR fusionados (30 d)
123

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de egdev6/quorb

Todos los issues de egdev6/quorb

Issues similares

Más issues de TypeScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.