Niri 26.04: compositor Wayland de mosaico con desplazamiento

• Compositor Wayland de mosaico con desplazamiento suma mejoras integrales en desenfoque de fondo, screencast, renderizado y manejo de entrada, elevando su nivel de acabado
• El desenfoque de fondo ya forma parte de la rama principal, por lo que las ventanas y elementos layer-shell compatibles con ext-background-effect pueden solicitar desenfoque sin configuración adicional de niri, y también se puede forzar desde reglas del lado de niri
• El screencast se pulió tanto en la ruta de PipeWire como en la de wlr-screencopy, incluyendo manejo del cursor, forma de iniciar dynamic cast, consultas y finalización forzada por IPC, además de problemas de copias múltiples y liberación de recursos
• La estructura de renderizado se reorganizó de un modelo basado en iterators a uno basado en push, con lo que la construcción de listas de renderizado es de 2 a 3 veces más rápida en las máquinas principales y hasta 8 veces más rápida en una Eee PC antigua, además de reducir el uso de memoria
• También se ajustó el soporte para hardware antiguo y entornos de entrada, ampliando el alcance de uso real con capturas de pantalla y screencast en sistemas Intel viejos, choques entre IME y popups de GTK 4, mapeo de mouse de alta tasa de sondeo y tabletas, y aceleración DMA-BUF en niri anidado

---

Cambios principales

• La organización de GitHub se movió de una cuenta personal a niri-wm, y también se reorganizaron los proyectos relacionados
  • awesome-niri: lista de proyectos relacionados
  • artwork: colección de insignias y fondos de pantalla
• También se incluyen cambios relacionados con el empaquetado
  • La versión mínima compatible de Rust sube a 1.85
  • niri.service ya no fija /usr/bin/ en la ruta del binario de niri
  • Cambia la estructura del archivo de servicio de dinit: 3bfa4a7

Desenfoque de fondo

• El desenfoque de fondo llegó a la rama principal, y las ventanas y componentes layer-shell pueden solicitar desenfoque mediante el protocolo ext-background-effect
  • Varias shells y apps pueden aprovecharlo de inmediato sin configuración adicional de niri
  • Dank Material Shell v1.4.5: se puede activar en la configuración
  • Shell Noctalia: ofrece configuración y documentación
  • Compatibilidad con el launcher Vicinae
  • foot v1.26: blur=true
  • kitty v0.46.2: background_blur 1
  • Ghostty: compatibilidad prevista en v1.4
  • Quickshell: compatibilidad prevista en v0.3
  • winit: compatibilidad prevista en v0.31
• Aunque una app todavía no sea compatible con ext-background-effect, se puede activar el desenfoque desde el lado de niri con window-rule y layer-rule
  • Los detalles de configuración y limitaciones están resumidos en la documentación de Window Effects
  • El desenfoque configurado en niri requiere un geometry-corner-radius correcto
  • No funciona con formas de surface complejas
• Se ofrecen xray blur y desenfoque normal, y el valor predeterminado es xray blur
  • xray blur calcula el desenfoque del fondo una sola vez y lo reutiliza como si fuera una imagen estática, por lo que es mucho más eficiente
  • Solo se vuelve a calcular cuando cambia el fondo de pantalla
  • Con fondos animados, la ventaja de eficiencia disminuye
  • Con el nuevo matcher layer, se puede cambiar para aplicar desenfoque normal solo a capas como top u overlay
• La implementación del desenfoque fue lo bastante compleja como para requerir cambios en la estructura de renderizado
  • El desenfoque normal vuelve a leer los píxeles ya renderizados a mitad del frame, los desenfoca y luego continúa con el renderizado
  • xray blur necesitó que la posición de la ventana se propagara por todo el código de renderizado para recortar correctamente el fondo
  • En Overview había que mantener la propiedad de no volver a renderizar la vista general, aun soportando xray blur
  • También debía funcionar junto con las ventanas bloqueadas para screencast
• Se puede usar solo xray sin desenfoque, y también aprovechar por separado el ruido para mitigar bandas de color y el efecto de saturation del blur
• El nuevo bloque popups permite aplicar transparencia y efectos de fondo también a menús emergentes desde window rule o layer rule
  • En casos que no son rectángulos redondeados, como popups de GTK 4 con has-arrow=true, la forma puede verse extraña
  • Las web apps o Electron no usan popups de Wayland, así que niri no puede manejarlos
  • Los clientes que implementan directamente ext-background-effect pueden manejar desenfoques de formas más complejas

Include opcional

• Se agregó include opcional a config include
  • Si se usa como include optional=true "optional-config.kdl", la carga de configuración no falla aunque el archivo no exista
  • Si el archivo no existe, se deja un warning en cada recarga de configuración, pero esta sigue cargándose
  • Si el archivo aparece después, el cambio monitoreado se detecta y se recarga automáticamente
  • Si el archivo existe pero tiene errores de sintaxis, sigue tratándose como fallo de parseo
• En las rutas de include, ~ se expande al directorio personal
  • ~/file.kdl se expande a /home/user/file.kdl

Warp del puntero y desplazamiento

• Durante los gestos para desplazarse por la vista, el puntero ahora hace warp de un extremo de la pantalla al opuesto
  • Es un comportamiento similar al de Blender
  • Esto permite seguir desplazándose de forma natural por varias ventanas aunque se empiece cerca del borde del monitor

Mejoras en la grabación de pantalla

• La grabación de pantalla de niri mejoró tanto con xdg-desktop-portal-gnome a través de PipeWire como mediante wlr-screencopy

• Manejo del cursor en la grabación de ventanas

  • Ahora PipeWire admite metadatos del cursor en lugar de dibujar el cursor directamente dentro de los fotogramas de video
    • El cursor no se incluye en el fotograma de video, sino que el ícono del cursor y sus coordenadas se envían en un búfer aparte
    • El lado consumidor, como OBS o un navegador, pasa a dibujar el cursor por su cuenta
  • Funciona tanto en captura de monitor como en captura de ventana
  • En la captura de ventana, el cursor solo se ve cuando realmente apunta a esa ventana o a sus popups
  • También se dibuja el ícono de arrastrar y soltar
  • Durante la implementación también salió a la luz un problema de corrupción de memoria en PipeWire y fue corregido
  • También se confirmó una discrepancia entre la intención de PipeWire y las implementaciones consumidoras como libwebrtc
  • En los entornos probados funciona correctamente
  • También se puede incluir el puntero en capturas de ventana con screenshot-window show-pointer=true

• Cambio en la forma de iniciar Dynamic cast target

  • Dynamic cast target es una función para cambiar de inmediato el objetivo de la grabación de pantalla mediante un atajo de teclado
  • Antes se abría al iniciar como un flujo de video de un píxel negro de 1×1
  • Ahora retrasa el inicio del flujo de video hasta que se seleccione el primer objetivo real
  • Esto evita el breve problema de video 1×1 en Microsoft Teams

• Cast IPC

  • Ahora se puede consultar por IPC qué grabaciones de pantalla están activas
  • niri msg casts permite ver los casts activos
  • Se pueden suscribir cast events en el event stream
  • El objeto Cast ofrece el tipo, el objetivo actual y el estado activo
  • La grabación de pantalla con PipeWire proporciona el node ID, y wlr-screencopy proporciona el ID del proceso cliente
  • DankMaterialShell ya muestra un indicador de grabación de pantalla mediante este IPC
  • niri msg action stop-cast --session-id <ID> permite forzar el cierre de una grabación de pantalla de PipeWire

• Limitaciones y correcciones relacionadas con wlr-screencopy

  • wlr-screencopy no tiene una forma robusta de distinguir entre grabación de pantalla y captura de pantalla, así que hacen falta algunas heurísticas
  • xdg-desktop-portal-wlr mantiene un único objeto wlr-screencopy manager de forma continua, por lo que es difícil saber de inmediato cuándo termina
  • Estos problemas se resuelven con el nuevo protocolo ext-image-copy-capture, pero todavía no ha llegado a niri

• Otras correcciones de grabación de pantalla

  • Se corrigió un problema por el que, al copiar damage, el cliente de wlr-screencopy siempre incluía el cursor aunque no lo quisiera
  • Se corrigió el comportamiento al solicitar simultáneamente varias copias de fotogramas con damage
  • Se corrigió un problema por el que, en algunos casos como cuando el cliente terminaba, los datos de wlr-screencopy de niri no se liberaban
  • Se redujo la cantidad predeterminada de búferes de grabación de pantalla de PipeWire de 16 a 8
  • Se ajustó el orden de los campos de la estructura para evitar un problema de use-after-free en pipewire-rs
  • Se corrigió un renderizado con z-order incorrecto durante un fotograma al cambiar el objetivo de dynamic cast a una ventana

Animaciones y comportamiento de ventanas

• La sincronización de animaciones ahora es más precisa
  • niri permite configurar animaciones individuales por separado, pero cuando deben encajar exactamente entre sí, las ejecuta de forma sincronizada
  • La animación de cambio de tamaño de ventana se sincroniza con la animación de desplazamiento horizontal de la vista que esa acción provoca
  • Se corrigió un problema por el que, al salir de fullscreen o maximize, faltaba la sincronización del desplazamiento de la vista, haciendo que la ventana volviera de inmediato mientras la pantalla se desplazaba lentamente
• Se corrigió un problema en el que se saltaba la animación de movimiento horizontal de otras ventanas en mosaico en ciertas rutas de arrastre
  • Ocurría por la superposición entre el comportamiento de arrastrar para sacar una ventana maximizada y desmaximizarla, y devolverla a floating si originalmente era flotante,
  • y la lógica de desplazamiento del workspace a izquierda y derecha al arrastrar cerca del borde del monitor
  • Commit de la corrección: df3f3979e936ed6800b4fbd55843bb0fe2554f15
• También se corrigió un problema por el que, al sacar la columna más a la izquierda del workspace y luego soltarla de nuevo, entraba a la derecha en lugar de volver a su posición original
• El tiempo de visualización de las notificaciones de error de configuración cambió para que no se vea afectado por los ajustes de slowdown/speedup de animación

IME y popups

• Se resolvió de forma alternativa un problema antiguo por el que los campos de entrada de popups en GTK 4 y el IME no funcionaban juntos
  • Con un IME como Fcitx5 activado, no se podían abrir popups de entrada de texto
  • El popup tomaba el grab del puntero y del teclado, y el IME también usa un grab de teclado, lo que provocaba un conflicto
  • niri soltaba el grab del popup y el popup solía cerrarse de inmediato
  • Se relajaron algunas comprobaciones para que funcione sin rehacer por completo la estructura de Smithay
  • Ahora los usuarios de IME pueden hacer tareas como renombrar archivos en Nautilus

Arrastrar y soltar, y dispositivos de entrada

• Ahora se puede cancelar una operación de arrastrar y soltar pulsando Escape
• También hubo varias correcciones generales en los dispositivos de entrada
  • Se corrigió un problema por el que el sistema se volvía cada vez más lento con el paso del tiempo al usar un mouse de alta tasa de sondeo junto con hide-after-inactive-ms o un daemon de monitoreo de inactividad
  • En libwayland-server v1.23 o superior, se aumenta el tamaño del búfer de Wayland para evitar que una ventana se cierre rápidamente al mover un mouse de alta tasa de sondeo sobre una ventana que no responde
  • Se agregó la opción de tableta map-to-focused-output, que permite mapearla a la salida actualmente enfocada en lugar de a una única salida fija
  • Se corrigió un problema por el que el cursor no siempre apuntaba con precisión a una ventana maximizada en el píxel superior del workspace
  • Se corrigió un problema por el que Alt-Tab respondía a la entrada del mouse antes de hacerse visible en pantalla
  • El desplazamiento on-button-down de trackball también funciona en overview
  • Se conserva el estado de Num Lock incluso después de cargar un custom .xkb keymap
  • Se corrigió un problema por el que no se podían usar dispositivos de entrada en absoluto al iniciar desde otra TTY a través de tmux
  • Se habilitó la carga de libinput plugins

Perfilado de GPU y optimización de renderizado

• Se añadió integración de perfilado de GPU a Tracy, que usan Smithay y niri
  • En Smithay se agregó el trabajo de enviar consultas de marcas de tiempo de GPU, recopilar los valores completados y enviarlos a Tracy: PR del trabajo
  • Ahora es posible marcar intervalos tanto para trabajos internos de GPU de Smithay como para trabajos de GPU del propio compositor
  • Se puede rastrear cómo se superponen el renderizado del búfer DRM y el renderizado del búfer de screencast de PipeWire dentro de un mismo frame
  • En sistemas multi-GPU también se pueden revisar pistas por cada GPU
  • Se pudo verificar que el rendimiento del blur no era más lento de lo esperado, y también se volvió más fácil diagnosticar dropped frames causados por cuellos de botella en el renderizado de GPU
• Se reestructuró la forma de construir la lista de renderizado de un enfoque basado en iterators a uno basado en push
  • Antes se combinaban elementos de renderizado con una forma tipo -> impl Iterator<Item = ...>
  • Había varias complejidades, como bifurcaciones condicionales, lifetime, préstamos de &self, conflictos con &mut Renderer, asignaciones intermedias de Vec y problemas en los límites entre crates
  • La nueva estructura hace que la función de renderizado reciba push: &mut dyn FnMut(Element) para ir insertando elementos
  • Las funciones intermedias pueden mantener la lógica existente con cierres que envuelven el push superior
  • Desaparecen los Vec temporales y también los problemas de borrowing
  • En niri, la ventaja de terminar antes con iterators en la práctica no era necesaria
• Con este refactor la velocidad de construcción de la lista de renderizado aumentó mucho
  • En la máquina principal fue de 2 a 3 veces más rápida
  • En una Eee PC antigua fue 8 veces más rápida
  • Construir la lista de renderizado no es el tiempo real de renderizado en la GPU en sí, pero como se ejecuta con frecuencia incluso cuando no hace falta redibujar la pantalla, la mejora tiene mucho impacto
  • También se redujo el uso de memoria, y en la nueva ruta la mayoría de las asignaciones restantes son solo para expandir el vector de salida
  • Los motivos detallados y el diff pueden verse en el PR

Soporte para hardware antiguo

• Se descubrió que la causa del fallo de capturas de pantalla en laptops Intel antiguas era un valor enum de OpenGL incorrecto en Smithay, y ya se corrigió: PR con el análisis de la causa
• Los shaders de niri también se optimizaron ligeramente para que incluso en la GPU limitada de una ASUS Eee PC muy antigua ahora funcionen
  • la animación de redimensionado de ventanas
  • las esquinas redondeadas del compositor

Otras mejoras

• Se corrigió un problema de fuga de VRAM que en algunos sistemas ocurría después de cerrar ciertas apps
• Se añadió el protocolo ext-foreign-toplevel-list, lo que facilita vincular objetos de ventana Wayland con IDs de ventana del IPC de niri en Quickshell y otros casos
• Si en la configuración hay un error por binds duplicados, ahora también se muestra la ubicación de la primera definición del mismo bind
• Al arrastrar una ventana con Mod+LMB se muestra un grabbing cursor
• Se añadió el argumento --path a niri msg action load-config-file, lo que permite cambiar a otro archivo de configuración en tiempo de ejecución
• El niri anidado ahora incluye soporte para DMA-BUF, por lo que la aceleración por hardware vuelve a funcionar incluso después de la eliminación de wl_drm en Mesa
• Se eliminó el padding que niri añadía a los popups de layer-shell cerca de los bordes del monitor
• También se incluyen cambios en la configuración predeterminada
  • Mod+M: maximize-window-to-edges
  • Mod+Shift+R: switch-preset-column-width-back
• Se añadió el flag de depuración force-disable-connectors-on-resume, que permite forzar la pantalla en blanco al cambiar de TTY o al volver del modo de suspensión
• Se corrigió para que en el fullscreen en ventana las esquinas de la ventana se procesen correctamente en ángulo recto
• Se corrigió un problema por el que la pantalla seguía redibujándose mientras el overview estaba abierto
• Se ajustó ligeramente el renderizado del gradient border con relative-to=workspace-view durante el arrastre interactivo
• Se refinó el renderizado del atajo con diéresis en el cuadro de diálogo Important Hotkeys
• Se corrigió la descripción de expel-window-from-column en niri msg action para que coincida con el comportamiento real: expulsar la ventana de abajo
• Se corrigieron varios panic que podían ocurrir cuando un cliente intentaba usar una output eliminada recientemente
• Se corrigió un problema donde clip-to-geometry rompía el renderizado al usarse con clientes que adjuntan búferes y_invert
• Se corrigió la compilación en OpenBSD
• El niri anidado ahora configura el app-id de su propia ventana
• Cuando se conecta una nueva GPU, se vuelve a evaluar la configuración de depuración ignore-drm-device, y también se pueden aprovechar los enlaces simbólicos de /dev/dri/by-path/

Incorporación de actualizaciones de Smithay

• Junto con la actualización de Smithay también llegaron varias mejoras de base
  • Se mejoró la selección automática de GPU en algunos dispositivos, como las Mac con ARM
  • Asahi y Pinephone ahora pueden funcionar directamente sin configurar manualmente render-drm-device
  • Mejoró el funcionamiento de algunos clientes layer-shell como wl_shimeji
  • Mejoró el soporte para docks cuyos EDID del monitor se cargan tarde
  • Las capturas de pantalla y los screencasts ahora funcionan en sistemas Intel antiguos
  • Se corrigió un problema donde quedaban outputs antiguas al desconectar un dock USB-C durante la suspensión
  • Se corrigió un panic de zxdg_exporter_v2 en algunos clientes
  • Se corrigió una fuga de memoria en clientes que no destruyen explícitamente el protocolo del portapapeles
  • Se corrigieron panic relacionados con content hint y purpose de text-input que empezaron a ocurrir en la release de desarrollo GTK 4.23
  • También mejoraron drag-and-drop, la entrada de texto IME, el soporte multi-GPU y el rendimiento general

[GN⁺]

Comentarios en Hacker News

• Niri me gustó tanto que me cambié hace como 5 meses, y desde entonces siento que ha sido una de las mejores decisiones que he tomado en los últimos años, junto con dejar Windows
  De verdad le estoy muy agradecido al autor
  Mis dotfiles originalmente incluían scripts de instalación para configuraciones de herramientas CLI, cambio de temas y demás, y ahora también soportan completamente Niri en distros basadas en Arch
  Si quieren probar rápido un entorno de escritorio nuevo, https://github.com/nickjj/dotfiles es un muy buen punto de partida
  Lo uso tanto en mi escritorio principal como en mi laptop de viaje

  • Igual por acá, y la combinación de monitor ultrawide curvo con Niri funciona especialmente bien
  • También deberían echarle un ojo a Nirimod
    Es no oficial, pero está realmente excelente
  • Omarchy metió algo así como un toggle de modo desplazable por workspace
    Presionas Win/Cmd + L y cambia entre tiling y scrolling, y la verdad ahora lo uso muchísimo

• Gracias a Niri conocí por primera vez la gestión de ventanas basada en scroll, y me hizo clic de inmediato
  Hace poco OmniWM para Mac recibió un modo de emulación completa de Niri por workspace, y por suerte también es compatible con Sequoia, así que enseguida se volvió mi window manager principal
  [1] https://github.com/BarutSRB/OmniWM

  • Paneru es una herramienta nueva para macOS hecha justamente con el objetivo de imitar a Niri
  • A mí me pasó algo parecido
    Cuando conocí por primera vez el enfoque de Niri me encantó, y desde entonces seguí buscando algo similar para Mac
    Es la mejor implementación que he probado hasta ahora, y aunque claramente tiene algunos quirks, al menos en mi caso sí da perfectamente para uso diario
    En especial, las columnas con pestañas están buenísimas
    Mis aplausos para el mantenedor y quienes contribuyen

• Si usas Mac, recomiendo OmniWM
  No solo tiene un layout estilo Niri, también otros más cercanos a Hyprland, y me ha hecho trabajar mucho más a gusto en macOS
  https://github.com/BarutSRB/OmniWM
  Ya lo había mencionado cuando apenas empezaba a usarlo, pero después de seguir con él puedo decir que de verdad está muy bien y lo recomiendo bastante

  • Perdón, pero el video de demo está al nivel de peor video de demo que he visto en mi vida
    No creo que nadie vaya a querer probar este software después de verlo, y hasta si ya fuera usuario me darían ganas de desinstalarlo

• Estoy usando la extensión PaperWM para GNOME, y supongo que Niri probablemente también se inspiró en eso
  Sin duda es una forma interesante de trabajar, pero cuando una workspace pasa de 3 ventanas se me empieza a hacer algo incómoda, así que no terminé enamorándome por completo
  Aun así la estoy usando en serio, y como es una extensión de GNOME, está bueno poder seguir usando el resto del DE de GNOME sin demasiada configuración

  • Durante bastante tiempo quise cambiarme a Niri, pero el proceso de ajustar toda la configuración adicional siempre me tomaba días
    Porque había que resolver también cosas como la barra superior, el idle timeout y las notificaciones
    Pero hace poco descubrí que existen desktop shells para Wayland, y te dan sin mucho esfuerzo la mayoría de lo que uno espera en un entorno como GNOME
    Incluyen diálogo de configuración, app tray, monitoreo de recursos y hasta top bar
    Ahora uso dank material shell, y está buenísimo poder mezclar desktop shell y compositor como se te dé la gana
  • Igual aquí, me gusta que PaperWM sea una extensión no invasiva de GNOME
    En general mejoró mi flujo de trabajo, pero además gracias a eso pude quitar otras dos o tres extensiones como desktop grid

• Ya estoy completamente acostumbrado al flujo de un tiling WM de pasar rápido entre varios workspaces fullscreen dedicados y gestionar ventanas solo con teclado
  Normalmente tengo una app por workspace, o una terminal con tmux, y solo de vez en cuando pongo dos apps lado a lado
  Me da mucha curiosidad cómo cambia el modelo mental para quienes se pasan a Niri desde un flujo parecido

  • Siempre he usado workspaces por actividad/proyecto en KDE, GNOME y Niri
    Un workspace con Steam y la wiki del juego, otro con Emacs y el navegador de documentación, otro con Godot y apps de desarrollo de juegos, ese tipo de organización
    Lo bueno de Niri es que casi no sientes presión de cerrar algo solo porque ya hay demasiadas ventanas
    Es bastante fácil separar y ordenar las cosas
    No entiendo muy bien por qué usar workspaces por app
    Tampoco me gusta tener mezcladas en un solo Firefox las pestañas del trabajo y del ocio
  • Fui usuario de tiling durante bastante tiempo, y mi configuración era parecida
    Pasé por awesome, qtile, un rato por xmonad, luego i3, después sway al moverme a Wayland, y también probé un poco hyprland
    El problema con el que siempre chocaba era que cuando pasabas de 3 ventanas, acomodarlas en horizontal ya no funcionaba bien y dividir en vertical las hacía demasiado pequeñas
    En cambio, sí era muy común querer abrir una ventana nueva junto a lo que estaba leyendo, o poner un gráfico de ipython al lado de la terminal
    Cada vez tenía que agruparlas en un layout apilado o moverlas a un workspace nuevo, y eso metía bastante fricción; la gestión de ventanas me interrumpía el flujo de trabajo
    En Niri, simplemente abres la nueva ventana y aparece donde la necesitas, mientras las otras se quedan a izquierda y derecha, listas para llegar a ellas con scroll
    Ahora mi workflow es un poco más desordenado que antes, pero justamente eso me gusta
    Los tiling WM tradicionales te exigen ordenar las cosas, y además lo facilitan; en Niri no hace falta ordenar nada si no quieres
    A veces, cuando no encuentro una ventana enseguida, uso el overview, y también le conecté búsqueda de ventanas con rofi
    Al principio seguí usando workspaces con nombre por costumbre de la época de sway, pero ya no lo hago
  • Yo llegué desde KDE con un flujo casi idéntico
    Workspace 1 era una terminal fullscreen con zellij, 2 el navegador, 3 un par de apps de chat, e iba cambiando con atajos
    Al principio usaba Niri porque era más ligero y diferente que Plasma, pero ahora también me cambió un poco el flujo de trabajo
    La mayoría de las ventanas siguen siendo del tamaño de la pantalla, y sigo organizando más o menos igual: 1 para desarrollo, 2 para navegador y a veces lector de correo, 3 para apps de chat
    Pero ahora sí abro nuevas ventanas de terminal mucho más seguido para teclear comandos cortos o dejar corriendo tareas largas
    En KDE esas ventanas quedaban apiladas detrás; ahora quedan una al lado de la otra dentro del workspace 1
    Viéndolo en retrospectiva, moverse con Alt-Tab ahora me parece bastante frustrante, y pasar con Super-hjkl se siente muchísimo más liviano
    Claro, esto depende de cada quien, pero el hecho de que las ventanas estén al lado en vez de superpuestas hace que el workflow se sienta más ligero
  • En realidad eso parece más una combinación de fullscreen y workspaces que tiling como tal
    Con un WM de mosaico manual como i3 o sway y un monitor grande, puedes dividir la pantalla en varias zonas de trabajo y poner varias apps por función en cada zona, reduciendo la cantidad de workspaces
    El scrolling es un flujo parecido pero distinto, y encaja especialmente bien cuando la flexibilidad importa en pantallas pequeñas
  • Un workspace por app no me parece que tenga mucho sentido en un tiling WM
    Ese flujo encaja mejor con un WM flotante
    La verdadera ventaja de un tiling WM está en realmente hacer tiling de las ventanas, y para mí la santa trinidad es tener navegador, editor y terminal visibles al mismo tiempo
    Y también poder moverte espacialmente con super+hjkl o con las flechas
    Por eso los workspaces por proyecto se sienten mucho más naturales, y más propios del flujo de un tiling WM
    Niri hace esto mucho mejor porque abre las ventanas nuevas a la derecha sin romper el layout actual
    Por ejemplo, puedes abrir un PDF y pasar fácilmente a esa nueva ventana sin desarmar la disposición que ya tenías

• Aquí van enlaces relacionados
  The dank case for scrolling window managers - https://news.ycombinator.com/item?id=46820468 - Jan 2026 (61 comments)
  Niri 25.11 released with alt-tab and other improvements - https://news.ycombinator.com/item?id=46097051 - Nov 2025 (1 comment)
  Niri – A scrollable-tiling Wayland compositor - https://news.ycombinator.com/item?id=45461500 - Oct 2025 (229 comments)
  The Future Is Niri - https://news.ycombinator.com/item?id=43342178 - March 2025 (216 comments)
  Niri: A scrollable-tiling Wayland compositor - https://news.ycombinator.com/item?id=37367687 - Sept 2023 (37 comments)

• Si quieren probar los dots de NNN (Niri-Nix-Noctalia), pueden tomar mi flake
  https://github.com/MostlyKIGuess/nix-flake-public

  • Usé window managers durante años, pero al final regresé a un entorno de escritorio completo por la barrera de tener que tocar hasta la configuración fuera del WM
    Incluso algo como el modo oscuro requería bastante trabajo, y Noctalia se ve justo como la dirección que yo quería
    Gracias por mencionarlo

• Estoy usando la rama wl-only de mangowm (basada en wlroots 0.20)
  Consume muchos menos recursos, tiene más layouts y da menos problemas
  Niri sí se ve mejor en lo visual, pero definitivamente vale la pena probarlo
  Si necesitas HDR, todavía toca esperar
  https://github.com/mangowm/mango

  • Me da curiosidad qué tipo de problemas son los que tiene menos
    En mi caso, Niri ha sido realmente rock solid

• Esto parece una historia de cómo un genio ruso hizo algo mejor que 100 millones de dólares en tokens de Claude
  Pero claro, no es para nada una locura colectiva, así que mejor todos vayan a comprar SPY

  • La verdad sí parece un genio
    Solo leer las notas de lanzamiento ya es casi una experiencia estética

• A finales del año pasado me pasé a Niri después de usar i3 por más de 10 años
  El scroll horizontal que no depende del tamaño del monitor, y la cantidad de workspaces que no depende del número de atajos configurados, se sienten realmente liberadores
  El nivel de pulido en lo gráfico también es bueno
  Pero la espinita que todavía queda es que la capa de compatibilidad con X, xwayland-satellite, todavía no soporta drag and drop entre apps X y apps Wayland
  [1]: https://davidyat.es/2026/01/28/niri/
  [2]: https://github.com/Supreeeme/xwayland-satellite/issues/133

  • Estoy en una situación parecida
    Antes tenía la costumbre de dejar siempre las mismas cosas en los mismos workspaces, así que era fácil acordarme; ahora la distribución termina mucho más dispersa
    Y sí extraño bastante scratch
    Supongo que podría arreglarlo afinando un poco más la configuración, pero todavía no le he dedicado ese tiempo