Niri 26.04: compositor Wayland de tiling com rolagem

 (github.com/niri-wm)
2 pontos por GN⁺ 3 일 전 | 1 comentários | Compartilhar no WhatsApp
  • O compositor Wayland de tiling com rolagem ganhou melhorias em desfoque de fundo, screencast, renderização e processamento de entrada, aumentando seu nível de maturidade
  • O desfoque de fundo foi incorporado ao mainline, permitindo que janelas e elementos layer-shell com suporte a ext-background-effect solicitem desfoque sem configuração extra no niri, e também possibilitando forçar o efeito por regras do lado do niri
  • O screencast foi refinado tanto no caminho com PipeWire quanto no com wlr-screencopy, incluindo tratamento de cursor, forma de iniciar casts dinâmicos, consulta e encerramento forçado via IPC, além de questões de cópia múltipla e liberação de recursos
  • A estrutura de renderização foi reorganizada de um modelo baseado em iterator para um baseado em push, tornando a montagem da lista de renderização de 2 a 3 vezes mais rápida nas máquinas principais e 8 vezes mais rápida em um Eee PC antigo, além de reduzir o uso de memória
  • Hardware antigo e ambientes de entrada também receberam ajustes, ampliando o uso prático com screenshots e screencasts em sistemas Intel antigos, conflitos entre IME e pop-ups do GTK 4, mapeamento de mouse de alta taxa de atualização e tablet, e aceleração DMA-BUF no niri aninhado

Principais mudanças

  • A organização no GitHub foi movida da conta pessoal para niri-wm, e os projetos relacionados também foram reorganizados
    • awesome-niri: lista de projetos relacionados
    • artwork: coleção de badges e papéis de parede
  • Também há mudanças para empacotadores
    • A versão mínima do Rust suportada subiu para 1.85
    • niri.service não fixa mais /usr/bin/ no caminho do binário do niri
    • A estrutura dos arquivos de serviço do dinit mudou: 3bfa4a7

Desfoque de fundo

  • O desfoque de fundo entrou no mainline, e janelas e componentes layer-shell podem solicitar desfoque pelo protocolo ext-background-effect
  • Mesmo que o app ainda não suporte ext-background-effect, é possível ativar o desfoque do lado do niri com window-rule e layer-rule
    • Os detalhes de configuração e limitações estão reunidos na documentação Window Effects
    • O desfoque configurado no niri exige geometry-corner-radius correto
    • Não funciona com formas de surface complexas
  • Há suporte tanto para xray blur quanto para blur comum, e o padrão é xray blur
    • O xray blur calcula o desfoque do papel de parede apenas uma vez e o reutiliza como uma imagem estática, sendo muito mais eficiente
    • Ele só é recalculado quando o papel de parede muda
    • Em papéis de parede animados, a vantagem de eficiência diminui
    • O novo matcher layer permite mudar isso para aplicar blur comum apenas em camadas como top e overlay
  • O recurso de desfoque teve implementação complexa, a ponto de exigir mudanças na estrutura de renderização
    • O blur comum relê pixels já renderizados no meio do frame, aplica o desfoque e então continua a renderização
    • O xray blur exigiu passar a posição da janela por todo o código de renderização para recortar corretamente o fundo
    • Era preciso manter a propriedade de a Overview continuar sem rerenderização mesmo com suporte a xray blur
    • Também precisava funcionar junto com as janelas bloqueadas no screencast
  • É possível usar apenas xray, sem blur, e também aproveitar separadamente ruído para reduzir banding do blur e efeito de saturação
  • O novo bloco popups permite aplicar transparência e efeitos de fundo também a menus pop-up em window rule ou layer rule
    • Em casos que não são retângulos arredondados, como pop-ups do GTK 4 com has-arrow=true, o formato pode ficar estranho
    • Web apps e Electron não usam pop-ups Wayland, então o niri não consegue tratá-los
    • Clientes que implementam ext-background-effect diretamente podem lidar com desfoque em formas mais complexas

Include opcional

  • O config include ganhou include opcional
    • Ao usar algo como include optional=true "optional-config.kdl", o carregamento da configuração não falha mesmo se o arquivo não existir
    • Se o arquivo não existir, um aviso é registrado a cada recarregamento da configuração, mas ela continua sendo carregada
    • Se o arquivo aparecer depois, a mudança monitorada será detectada e a configuração será recarregada automaticamente
    • Se o arquivo existir mas tiver erro de sintaxe, isso continua sendo tratado como falha de parsing
  • O ~ no caminho de include agora é expandido para o diretório home
    • ~/file.kdl passa a ser expandido para /home/user/file.kdl

Warping do ponteiro e rolagem

  • Durante gestos de rolagem da visualização, o ponteiro agora é transportado de uma borda da tela para a oposta
    • O comportamento é semelhante ao do Blender
    • Isso permite continuar rolando naturalmente por várias janelas, mesmo começando perto da borda do monitor

Melhorias no screencast

  • O screencast do niri foi melhorado tanto no modo via xdg-desktop-portal-gnome através do PipeWire quanto via wlr-screencopy

  • Tratamento do cursor no screencast de janelas

    • O PipeWire agora passa a oferecer suporte a metadados de cursor em vez de desenhar o cursor diretamente dentro do frame de vídeo
      • O cursor não entra no frame de vídeo; o ícone do cursor e suas coordenadas são enviados em um buffer separado
      • O lado consumidor, como OBS ou navegadores, passa a desenhar o cursor por conta própria
    • Funciona tanto em captura de monitor quanto em captura de janela
    • Na captura de janela, o cursor só aparece quando estiver realmente apontando para aquela janela ou para seus pop-ups
    • Ícones de arrastar e soltar também são desenhados junto
    • Durante a implementação, também foi revelado e corrigido um problema de corrupção de memória no PipeWire
    • Também foi confirmada uma divergência entre a intenção do PipeWire e implementações consumidoras como libwebrtc
    • Nos ambientes testados, funcionou corretamente
    • Agora também é possível incluir o ponteiro em capturas de tela de janela com screenshot-window show-pointer=true

  • Mudança no modo de iniciar o Dynamic cast target

    • O Dynamic cast target é um recurso que troca imediatamente o alvo do screencast por atalho de teclado
    • Antes, ele era aberto no início com um stream de vídeo preto de 1×1 pixel
    • Agora, o início do stream de vídeo é adiado até que o primeiro alvo real seja selecionado
    • Isso evita o breve problema de vídeo 1×1 no Microsoft Teams

  • Cast IPC

    • Agora é possível verificar via IPC os screencasts em andamento
    • niri msg casts mostra os casts ativos
    • É possível assinar eventos de cast no event stream
    • O objeto Cast fornece tipo, alvo atual e estado ativo
    • Screencasts via PipeWire fornecem o node ID, e o wlr-screencopy fornece o ID do processo cliente
    • O DankMaterialShell já exibe um indicador de screencast usando esse IPC
    • É possível encerrar à força um screencast do PipeWire com niri msg action stop-cast --session-id <ID>

  • Limitações e correções relacionadas ao wlr-screencopy

    • O wlr-screencopy não tem uma forma robusta de diferenciar screencast de captura de tela, então alguns heurísticos são necessários
    • O xdg-desktop-portal-wlr mantém um único objeto wlr-screencopy manager continuamente, o que dificulta saber imediatamente quando ele terminou
    • Esses problemas são resolvidos no novo protocolo ext-image-copy-capture, mas ele ainda não chegou ao niri

  • Outras correções de screencast

    • Foi corrigido um problema em que, ao copiar damage, clientes wlr-screencopy sempre incluíam o cursor mesmo quando não o queriam
    • Foi corrigido o comportamento ao solicitar ao mesmo tempo várias cópias de frames com damage
    • Foi corrigido um problema em que os dados de wlr-screencopy no niri não eram liberados em alguns casos, como quando o cliente era encerrado
    • O número padrão de buffers de screencast do PipeWire foi reduzido de 16 para 8
    • A ordem dos campos de struct foi ajustada para evitar um problema de use-after-free no pipewire-rs
    • Foi corrigida a renderização com z-order incorreta durante um frame ao trocar o alvo de cast dinâmico para uma janela

Animações e comportamento de janelas

  • A sincronização de animações ficou mais precisa
    • O niri permite configurar animações individualmente, mas quando algumas precisam coincidir com precisão, elas passam a rodar sincronizadas
    • A animação de redimensionamento de janela é sincronizada com a animação de deslocamento horizontal da view que ela provoca
    • Foi corrigido um problema em que, ao sair de fullscreen ou maximizado, faltava a sincronização do deslocamento da view, então a janela voltava na hora enquanto a tela só rolava lentamente depois
  • Também foi corrigido um problema em que a animação de movimento horizontal de outras janelas em tile era pulada em certos caminhos de arraste
    • Isso acontecia por causa da sobreposição entre o comportamento de arrastar para desfazer uma janela maximizada e, se ela originalmente fosse flutuante, devolvê-la ao modo floating,
    • e a lógica de rolagem de workspace para a esquerda ou direita ao arrastar perto da borda do monitor
    • Commit da correção: df3f3979e936ed6800b4fbd55843bb0fe2554f15
  • Também foi corrigido um problema em que, ao puxar a coluna mais à esquerda da workspace e soltá-la de volta, ela ia para a direita em vez de voltar ao lugar original
  • O tempo de exibição das notificações de erro de configuração agora não é afetado pelas configurações de slowdown/speedup de animação

IME e pop-ups

  • Foi contornado um problema antigo em que campos de entrada de pop-up do GTK 4 e IME não funcionavam juntos
    • Com um IME como o Fcitx5 ativado, não era possível abrir pop-ups de entrada de texto
    • O conflito acontecia porque o pop-up capturava pointer e teclado, e o IME também usa captura de teclado
    • O niri acabava soltando a captura do pop-up, e ele se fechava imediatamente
    • Algumas verificações foram flexibilizadas para que isso funcionasse sem mudar completamente a estrutura do Smithay
    • Agora usuários de IME podem fazer coisas como renomear arquivos no Nautilus

Arrastar e soltar e dispositivos de entrada

  • Agora é possível cancelar uma operação de arrastar e soltar pressionando Escape
  • Várias correções também foram aplicadas aos dispositivos de entrada em geral
    • Foi corrigido um problema de lentidão progressiva ao usar um mouse de alta taxa de atualização junto com hide-after-inactive-ms ou um daemon de monitoramento de idle
    • No libwayland-server v1.23 ou superior, o tamanho do buffer do Wayland foi aumentado para evitar que janelas travem rapidamente ao mover um mouse de alta taxa de atualização sobre uma janela sem resposta
    • Foi adicionada a opção de tablet map-to-focused-output, que permite mapear para a saída atualmente focada em vez de uma única saída especificada
    • Foi corrigido um problema em que o cursor nem sempre apontava com precisão para uma janela maximizada no pixel mais alto da workspace
    • Foi corrigido um problema em que o Alt-Tab reagia à entrada do mouse antes de aparecer na tela
    • O scroll on-button-down do trackball também funciona no overview
    • O estado do Num Lock agora é preservado mesmo após carregar um keymap .xkb personalizado
    • Foi corrigido um problema em que dispositivos de entrada não funcionavam de forma alguma ao iniciar a partir de outro TTY via tmux
    • O carregamento de plugins do libinput foi ativado

Perfilamento de GPU e otimização de renderização

  • Foi adicionada a integração de perfilamento de GPU do Tracy, usado no Smithay e no niri
    • O Smithay passou a incluir o envio de consultas de timestamp da GPU, a coleta dos valores concluídos e o envio deles ao Tracy: PR do trabalho
    • Agora é possível marcar intervalos tanto para trabalhos internos de GPU do Smithay quanto para trabalhos de GPU do próprio compositor
    • É possível rastrear como a renderização de buffers DRM e a renderização de buffers de screencast do PipeWire se sobrepõem em um único frame
    • Em sistemas com múltiplas GPUs, também é possível verificar trilhas por GPU
    • Foi possível verificar que o desempenho do blur não é mais lento do que o esperado, e também ficou mais fácil diagnosticar dropped frames causados por gargalos na renderização da GPU
  • A forma de composição da lista de renderização foi reestruturada de um modelo baseado em iterator para um modelo baseado em push
    • Antes, os elementos de renderização eram combinados no formato -> impl Iterator<Item = ...>
    • Havia várias complexidades, como ramificações condicionais, lifetime, empréstimo de &self, conflitos com &mut Renderer, alocação intermediária de Vec e problemas nos limites entre crates
    • Na nova estrutura, a função de renderização recebe push: &mut dyn FnMut(Element) e insere os elementos por meio dele
    • As funções intermediárias podem manter a lógica existente com closures que encapsulam o push superior
    • O Vec temporário desapareceu e os problemas de borrowing também foram eliminados
    • No niri, a vantagem de encerramento antecipado do iterator não era necessária na prática
  • Com essa refatoração, a velocidade de composição da lista de renderização aumentou bastante
    • Na máquina principal, houve ganho de 2 a 3 vezes
    • Em um Eee PC antigo, houve ganho de 8 vezes
    • A composição da lista de renderização não é o tempo real de renderização da GPU em si, mas é executada com frequência mesmo quando a tela não precisa ser redesenhada, então a melhoria tem grande efeito
    • O uso de memória também caiu, e na nova rota a maioria das alocações restantes se limita à expansão do vetor de saída
    • Mais detalhes sobre a motivação e o diff podem ser vistos no PR

Suporte a hardware antigo

  • Descobriu-se que a causa do problema de falha em screenshots em notebooks Intel antigos era um valor de enum OpenGL incorreto no Smithay, e isso foi corrigido: PR com a análise da causa
  • Os shaders do niri também foram levemente otimizados para que, mesmo em uma GPU limitada de um ASUS Eee PC muito antigo,
    • a animação de redimensionamento de janelas
    • e os cantos arredondados do compositor
    • passem a funcionar

Outras melhorias

  • Foi corrigido um problema de vazamento de VRAM que ocorria em alguns sistemas após o encerramento de certos aplicativos
  • O protocolo ext-foreign-toplevel-list foi adicionado, facilitando a ligação entre objetos de janela Wayland e IDs de janela do IPC do niri em ambientes como o Quickshell
  • Quando ocorre erro de bind duplicado na configuração, a posição da primeira definição do mesmo bind também é exibida
  • Ao arrastar janelas com Mod+LMB, passa a ser exibido o cursor de grabbing
  • Foi adicionado o argumento --path a niri msg action load-config-file, permitindo alternar para outro arquivo de configuração em tempo de execução
  • O niri aninhado ganhou suporte a DMA-BUF, fazendo a aceleração por hardware voltar a funcionar mesmo após a descontinuação de wl_drm no Mesa
  • Foi removido o padding que o niri aplicava a pop-ups layer-shell perto das bordas do monitor
  • Também há mudanças na configuração padrão
    • Mod+M: maximize-window-to-edges
    • Mod+Shift+R: switch-preset-column-width-back
  • Foi adicionada a flag de depuração force-disable-connectors-on-resume, permitindo forçar a tela a ficar em branco ao alternar TTY ou voltar da suspensão
  • Foi corrigido o tratamento para que os cantos da janela em fullscreen em janela fiquem corretamente em ângulo reto
  • Foi corrigido um problema em que a tela continuava sendo redesenhada enquanto o overview estava aberto
  • Durante arrasto interativo, a renderização da gradient border com relative-to=workspace-view foi levemente ajustada
  • Foi refinada a renderização do atalho de trema na caixa de diálogo Important Hotkeys
  • A descrição de expel-window-from-column em niri msg action foi corrigida para corresponder ao comportamento real, expulsando a janela de baixo
  • Foram corrigidos vários panics que podiam ocorrer quando clientes tentavam usar uma output removida recentemente
  • Foi corrigido um problema de renderização corrompida quando clip-to-geometry era usado junto com clientes que anexavam buffers y_invert
  • Foi corrigido o build no OpenBSD
  • O niri aninhado agora passou a definir o app-id da própria janela
  • Quando uma nova GPU é conectada, a configuração de depuração ignore-drm-device é reavaliada para também poder usar links simbólicos em /dev/dri/by-path/

Atualizações do Smithay incorporadas

  • Com a atualização do Smithay, várias melhorias de base também entraram juntas
    • A seleção automática de GPU foi melhorada em alguns dispositivos, como Macs ARM
    • Asahi e Pinephone passaram a funcionar diretamente sem configuração manual de render-drm-device
    • O funcionamento de alguns clientes layer-shell, como wl_shimeji, foi melhorado
    • O suporte a docks cujo EDID do monitor é carregado tardiamente foi melhorado
    • Screenshots e screencast passaram a funcionar em sistemas Intel antigos
    • Foi corrigido um problema em que outputs antigas permaneciam após desconectar um dock USB-C durante a suspensão
    • Foi corrigido um panic de zxdg_exporter_v2 em alguns clientes
    • Foi corrigido um vazamento de memória em clientes que não destroem explicitamente o protocolo de clipboard
    • Foi corrigido um panic relacionado a content hint e purpose de text-input, que começou a ocorrer em releases de desenvolvimento do GTK 4.23
    • Também houve melhorias gerais em drag-and-drop, entrada de texto via IME, multi-GPU e desempenho

Leituras relacionadas

1 comentários

 
GN⁺ 3 일 전
Comentários no Hacker News

  • Gostei tanto do Niri que mudei para ele há uns 5 meses e, desde então, parece uma das melhores decisões que tomei nos últimos anos, junto com ter saído do Windows
    Sou muito grato ao autor
    Meus dotfiles já incluíam scripts de instalação para configurações de ferramentas CLI, troca de temas etc., e agora também dão suporte completo ao Niri nas distros da família Arch
    Se você quiser experimentar rápido um novo ambiente de desktop, https://github.com/nickjj/dotfiles é um ótimo ponto de partida
    Estou usando tanto no desktop principal quanto no notebook de viagem

    • Mesma coisa aqui, e a combinação de monitor ultrawide curvo com Niri funciona especialmente bem
    • Vale muito a pena dar uma olhada no Nirimod
      É não oficial, mas realmente excelente
    • O Omarchy adicionou esse tipo de alternância do modo scrollable por workspace
      Você aperta Win/Cmd + L para alternar entre tiling e scrolling, e hoje uso isso com bastante frequência

  • Foi com o Niri que conheci pela primeira vez o gerenciamento de janelas baseado em rolagem, e fez sentido na hora
    Recentemente o OmniWM para Mac ganhou um modo de emulação completa do Niri por workspace e, felizmente, também é compatível com o Sequoia, então virou meu window manager principal na hora
    [1] https://github.com/BarutSRB/OmniWM

    • Paneru é uma ferramenta nova para macOS criada justamente com o objetivo de imitar o Niri
    • Comigo foi parecido
      Quando conheci a abordagem do Niri, gostei muito, e continuei procurando algo parecido também no Mac
      De tudo que já testei, é a melhor implementação; com certeza tem algumas quirks pequenas, mas pelo menos no meu caso é bom o bastante para usar como daily driver
      As tabbed columns em especial são excelentes
      Palmas para o mantenedor e os contribuidores

  • Se você usa Mac, recomendo o OmniWM
    Além do layout no estilo do Niri, ele também oferece layouts mais próximos do Hyprland, e isso deixou meu trabalho no macOS muito mais agradável
    https://github.com/BarutSRB/OmniWM
    Eu já tinha postado sobre ele quando comecei a usar, mas depois de continuar usando posso dizer que é realmente bom e vale uma recomendação forte

    • Desculpa, mas o vídeo de demonstração está no nível de pior vídeo de demo que já vi na vida
      Acho que ninguém vai querer testar esse software depois de ver aquilo, e mesmo quem já usa talvez fique com vontade de apagar

  • Estou usando a extensão PaperWM para GNOME, e imagino que o Niri também tenha tirado inspiração daí
    É com certeza uma forma de trabalho interessante, mas quando uma workspace passa de 3 janelas, começa a parecer meio incômodo, então nunca consegui amar completamente
    Ainda assim, estou realmente tentando usar, e por ser uma extensão do GNOME é bom poder continuar usando o restante do GNOME DE sem precisar de configuração excessiva

    • Faz tempo que eu queria migrar para o Niri, mas o processo de acertar as configurações complementares sempre levava dias
      Porque precisava resolver tudo também: top bar, idle timeout, notificações e por aí vai
      Só que recentemente descobri que existem desktop shells para Wayland, e eles oferecem a maior parte do que se espera de um ambiente tipo GNOME sem muito esforço
      Incluem caixa de diálogo de configuração, app tray, monitoramento de recursos e top bar
      Agora estou usando o dank material shell, e é muito legal poder combinar desktop shell e compositor do jeito que você quiser
    • Mesma coisa aqui, gosto do fato de o PaperWM ser uma extensão não intrusiva do GNOME
      Além de o workflow ter melhorado no geral, isso também me permitiu remover outras duas ou três extensões, como a desktop grid

  • Já me acostumei completamente com o fluxo de um tiling WM de alternar rapidamente entre vários workspaces fullscreen dedicados e fazer gerenciamento de janelas só com o teclado
    Normalmente deixo um app por workspace, ou um terminal com tmux, e só às vezes coloco dois apps lado a lado
    Tenho muita curiosidade de saber como muda o modelo mental de quem vem de um fluxo parecido e migra para o Niri

    • Sempre usei workspaces por atividade/projeto no KDE, GNOME e Niri
      Um workspace com Steam e wiki do jogo, outro com Emacs e navegador de documentação, outro com Godot e apps de desenvolvimento de jogos
      O legal do Niri é que quase não existe aquela pressão de sentir que há janelas demais e que você precisa fechar alguma coisa
      É bem fácil separar e organizar
      Não entendo muito por que usar workspaces por app
      Também detesto ter trabalho e hobby tudo misturado nas abas de um único Firefox
    • Fui usuário de tiling por bastante tempo e minha configuração era parecida
      Usei awesome, qtile, xmonad por um tempo, depois i3, depois sway ao migrar para Wayland, e também um pouco de hyprland
      O problema em que eu sempre esbarrava era que, passando de 3 janelas, o arranjo horizontal deixava de funcionar bem e as divisões verticais ficavam pequenas demais
      Por outro lado, eu frequentemente queria abrir uma nova janela ao lado do que estava lendo, ou mostrar um gráfico do ipython ao lado do terminal
      Toda vez eu precisava agrupar em stacked layout ou mover para outro workspace, o que criava bastante atrito e interrompia meu fluxo de trabalho por causa do gerenciamento de janelas
      No Niri, eu simplesmente abro a nova janela e ela aparece onde preciso, enquanto as outras continuam à esquerda e à direita, acessíveis com scroll
      Hoje meu workflow está um pouco mais bagunçado do que antes, mas justamente por isso acho melhor
      Os tiling WMs tradicionais exigem organização e também facilitam isso, mas no Niri você não precisa necessariamente organizar tudo
      Quando às vezes não encontro uma janela de imediato, uso o overview, e também conectei busca de janelas com o rofi
      No começo eu ainda usava workspaces nomeados por hábito da época do sway, mas agora não uso mais
    • Vim do KDE com um fluxo quase idêntico
      Workspace 1 era um terminal fullscreen com zellij, 2 era o navegador, 3 eram uns dois apps de chat, e eu alternava com atalhos
      No começo usei o Niri por ser mais leve e diferente do Plasma, mas hoje meu workflow também mudou um pouco
      A maioria das janelas ainda usa basicamente o tamanho da tela inteira, e continuo organizando parecido: 1 para desenvolvimento, 2 para navegador e às vezes leitor de e-mail, 3 para apps de chat
      Mas agora abro novas janelas de terminal com muito mais frequência para digitar comandos curtos ou deixar tarefas longas rodando
      No KDE essas janelas ficavam empilhadas atrás; agora elas ficam lado a lado dentro do workspace 1
      Pensando bem, o jeito antigo de alternar com Alt-Tab agora parece bem travado, e navegar com Super-hjkl é muito mais leve
      Claro, varia de pessoa para pessoa, mas a sensação de as janelas ficarem ao lado umas das outras em vez de sobrepostas deixa o workflow mais leve
    • Isso na verdade parece menos tiling e mais uma combinação de fullscreen com workspaces
      Com um WM de tiling manual como i3 ou sway e um monitor grande, dá para dividir a tela em várias áreas de trabalho e manter vários apps com papéis diferentes em cada área, reduzindo o número de workspaces
      Scrolling é um fluxo parecido, mas diferente, e funciona especialmente bem quando a flexibilidade é importante em telas pequenas
    • Um workspace por app não faz muito sentido em tiling WM, na minha opinião
      Esse fluxo combina mais com floating WM
      A verdadeira vantagem de um tiling WM está em realmente colocar as janelas em tiles, e para mim a holy trinity de navegador, editor e terminal visíveis ao mesmo tempo é o principal
      E você precisa conseguir se mover espacialmente com super+hjkl ou com as setas
      Por isso workspaces por projeto parecem muito mais naturais e mais alinhados com a proposta de um tiling WM
      O Niri faz isso muito melhor porque abre novas janelas à direita sem destruir o layout atual
      Por exemplo, você pode abrir um PDF e passar facilmente para essa nova janela sem perder a organização que já tinha

  • Links 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)

  • Se quiser testar os dots do NNN (Niri-Nix-Noctalia), pode pegar meu flake
    https://github.com/MostlyKIGuess/nix-flake-public

    • Usei window manager por anos, mas acabei voltando para um ambiente de desktop pronto por causa da barreira de ter que mexer até nas configurações fora do WM
      Só para coisas como dark mode já dava trabalho, e o Noctalia parece exatamente a direção que eu queria
      Valeu por mencionar

  • Estou usando o branch wl-only do mangowm (baseado em wlroots 0.20)
    Consome bem menos recursos, tem mais layouts e menos problemas
    O Niri parece ter efeitos visuais melhores, mas ainda assim vale muito testar
    Se você precisa de HDR, ainda vai ter que esperar
    https://github.com/mangowm/mango

    • Fiquei curioso sobre que problemas seriam esses que ele tem menos
      No meu caso, o Niri foi realmente rock solid

  • Parece aquela história de que um gênio russo acabou de criar algo melhor do que 100 milhões de dólares em tokens do Claude
    Mas claro, isso não é nem um pouco uma loucura coletiva, então a vibe é que todo mundo deveria comprar SPY

    • Parece mesmo um gênio
      As release notes são bonitas num nível quase artístico

  • No fim do ano passado, migrei para o Niri depois de mais de 10 anos usando i3
    O scroll horizontal que não fica preso ao tamanho do monitor, e a quantidade de workspaces que não fica presa ao número de atalhos configurados, passam uma sensação real de liberdade
    O acabamento gráfico também é muito bom
    A única frustração que ainda resta é que a camada de compatibilidade X, o xwayland-satellite, ainda não suporta drag and drop entre apps X e apps Wayland
    [1]: https://davidyat.es/2026/01/28/niri/
    [2]: https://github.com/Supreeeme/xwayland-satellite/issues/133

    • Situação parecida aqui
      Antes eu lembrava fácil porque tinha o hábito de manter sempre as mesmas coisas nos mesmos workspaces, mas agora a disposição acaba ficando mais espalhada
      E sinto bastante falta de um scratch
      Acho que daria para resolver mexendo mais na configuração, mas ainda não investi esse tempo