Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

bug(linux/wayland): la ventana no se puede posicionar: tira centrada, arrastre y cambio de monitor inoperativos

Aperta
  • Qualcosa non va?
#180 2 commenti 0 reazioni 1 assegnatario Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

@SrStamm ci sta già lavorando.

Dal 25/10/2026.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
45/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
linux, rust, tauri, typescript
Ambito
desktop

Direzione di ricerca

Start from Widget.tsx:831 where getCurrentWindow().setPosition is called and detail_geometry.rs:56 where initial anchoring uses window.set_position. Reproduce under Wayland with npm run app:dev on GNOME, confirm window stays centered. Done means window docks to dockEdge and drag works, or app explicitly declares Wayland limitation.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

type:bug
Pre-flight checks
  • I searched existing issues and found no duplicate.
  • I understand that this report enters review before implementation.
What happened?

Bajo sesión Wayland nativa la ventana del widget no se puede colocar en ningún
punto de la pantalla. Se observan tres síntomas con una sola causa:

  1. La tira queda centrada en la pantalla en lugar de anclarse al borde
    configurado (dockEdge: "right"), y no se reposiciona nunca.
  2. El arrastre no mueve la ventana: el gesto se registra (el cursor cambia a
    grabbing), la aritmética interna calcula la nueva coordenada, pero la
    ventana no se desplaza.
  3. No hay forma de llevar el widget a otro monitor (probado con una segunda
    pantalla): el arrastre tampoco cruza, y Settings.tsx no expone ningún
    selector de monitor (grep de dockMonitor en Settings.tsx sin resultados;
    el campo existe en config.json y solo lo escribe el widget al acoplar).

Consecuencia funcional: en Wayland el widget no cumple la premisa de estar
dockeado a un borde. Las mitigaciones que muestra «Ajustes › Sesión de
escritorio» no pueden aplicarse (ver detalle técnico abajo).

Steps to reproduce
  1. Ejecutar Quorb desde main en una sesión Wayland nativa
    (XDG_SESSION_TYPE=wayland), p. ej. Ubuntu 26.04 con GNOME (Mutter).
    Lanzamiento: npm run app:dev.
  2. Observar que la tira aparece en el centro de la pantalla, no en el borde
    derecho (dockEdge: "right", dockOffset: 0.742).
  3. Pulsar el asa de arrastre y arrastrar: el cursor cambia a grabbing, pero la
    ventana no se mueve (mismo síntoma que el punto 4 de #168, acá en GNOME).
  4. Conectar una segunda pantalla y arrastrar hacia ella: tampoco llega.
  5. En Ajustes no existe opción para elegir la pantalla destino.
Expected behavior
  1. La tira se ancla al borde configurado, o la app declara explícitamente que el
    anclaje no está disponible en este compositor y ofrece la alternativa real.
  2. El arrastre mueve la ventana y al soltar se imanta al borde más cercano
    (comportamiento verificado y funcional bajo X11).
  3. Existe una vía (selector en Ajustes o arrastre) para elegir el monitor
    destino, o su ausencia queda declarada en el bloque de compatibilidad.
Environment
OS: Ubuntu 26.04.1 LTS (Resolute Raccoon), x86_64
Session: XDG_SESSION_TYPE=wayland, XDG_CURRENT_DESKTOP=ubuntu:GNOME (Mutter)
Toolkit: WebKitGTK 2.52.6 (Tauri 2, tao 0.37.1, GTK 3.24.52)
Quorb: main @ 404dca5 (post #169), ejecutado con `npm run app:dev`
Config: dockEdge=right, dockOffset=0.742, autoHide=true, alwaysOnTop=true
Affected area

Application behavior

Agent or client (for MCP or headless incidents)

No response

Shell (for MCP or headless incidents)

No response

Anexo: detalle técnico

La cadena hasta la causa raíz

Cadena completa verificada en el código de esta revisión:

Widget.tsx:831   getCurrentWindow().setPosition(new PhysicalPosition(x, y))   ← arrastre
detail_geometry.rs:56   window.set_position(...)                             ← anclaje inicial (set_widget_bounds)
        ↓
tao 0.37.1  platform_impl/linux/window.rs:472   set_outer_position → WindowRequest::Position
        ↓
tao 0.37.1  platform_impl/linux/event_loop.rs:301   window.move_(x, y)
        ↓
GTK3  gtk_window_move()   →  SIN EFECTO bajo Wayland (documentado por GTK: solo opera en X11)

Es decir: el cálculo de posición funciona, el envío funciona, y la primitiva
final es un no-op en Wayland. Por eso #169 (que arregló el origen de la
aritmética del arrastre, que usaba outerPosition() = (0,0)) no alcanza para
que la ventana se mueva: falta el lado de salida.

Relación con issues existentes (no es duplicado)
  • #168 (abierta, KDE/Wayland): su punto 4 es «arrastrre congelado» y su
    análisis de causa raíz atribuye el síntoma al origen falso outerPosition()
    = (0,0). El fix correspondiente ya está en main (líneas 796-826 de
    Widget.tsx usan widgetBounds como origen) y el síntoma persiste en
    GNOME    : la causa restante es la de este reporte (salida no-op). Evidencia
    complementaria, no duplicado.
  • #179 (abierta, X11/XWayland sobre KDE): mide que bajo X11 el arrastre sí
    transporta la ventana     (406×270 px medidos) y solo fallan los márgenes
    finales. Eso es el contrapunto experimental: mismos archivos de
    arrastre/geometría que main, y el fallo solo aparece en el backend Wayland.
  • #113 (abierta, feat): dock al monitor principal y aviso de monitor
    externo. Comparte el terreno de «monitor» pero es una mejora de elección de
    monitor, no la imposibilidad de mover la ventana.
  • #147 (cerrada, fix): recuperación de posición/natur corruptos; no cubre
    posicionamiento inicial bajo Wayland.
Límites honestos de esta medición
  • Medido en GNOME/Mutter; KDE no se probó en esta sesión (el arrastre bajo
    X11/XWayland en KDE sí está medido en #179).
  • La app se ejecutó desde npm run app:dev (binario debug); no se probó el
    .deb/AppImage instalado en esta ronda.
Lingua principale
TypeScript
Stelle
10
Fork
2
Merge medio
3h 54m
PR unite (30g)
96

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di egdev6/quorb

Tutte le issue di egdev6/quorb

Issue simili

Altre issue su TypeScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.