- Nos ambientes Wayland tradicionais, o compositor e o gerenciador de janelas eram combinados em um único programa, mas o river 0.4.0 os separa em processos distintos
- O novo protocolo river-window-management-v1 dá ao gerenciador de janelas autoridade total sobre políticas como organização de janelas e atalhos de teclado, mantendo ao mesmo tempo a perfeição de quadros (frame perfection) e o desempenho
- Essa estrutura funciona sem latência de entrada, e mesmo em layouts de mosaico complexos garante renderização limpa por meio de atualizações atômicas de estado
- Graças à arquitetura separada, o gerenciador de janelas pode ser desenvolvido e reiniciado de forma independente, além de ser fácil de implementar também em linguagens de alto nível
- Essa abordagem incentiva a expansão da diversidade de gerenciadores de janelas no ecossistema Wayland, e o river já oferece suporte a mais de 15 gerenciadores compatíveis
Estrutura tradicional do Wayland e a abordagem separada do river
- Os compositores Wayland tradicionais integravam em um único processo três papéis: servidor de exibição, compositor e gerenciador de janelas
- O servidor de exibição roteia eventos de entrada e entrega os buffers de exibição ao kernel
- O compositor combina os buffers de várias janelas para gerar a tela final
- O gerenciador de janelas cuida de políticas do usuário, como disposição das janelas e atalhos de teclado
- Na arquitetura do X11, o servidor de exibição existe como processo separado, o que gera comunicação de ida e volta desnecessária e latência
- O Wayland resolveu isso ao integrar servidor e compositor, mas não era obrigatório acoplar também o gerenciador de janelas
- O river desfaz esse acoplamento e separa o gerenciador de janelas em um programa distinto
Princípios de projeto do protocolo river-window-management-v1
- Projetado para que o gerenciador de janelas tenha controle máximo, mantendo as vantagens do Wayland
- Não exige comunicação de ida e volta a cada quadro nem a cada evento de entrada, portanto não há latência de entrada
- Mantém a perfeição de quadros (frame perfection): quando uma janela é aberta ou redimensionada, garante atualização da tela sem lacunas nem sobreposições
- A renderização é adiada até que todas as janelas enviem seus novos buffers, mas, se passar de um certo tempo, entra um timeout
- Quanto melhor implementado for o aplicativo, maior a chance de sincronização perfeita de quadros
Estrutura de gerenciamento de janelas baseada em máquina de estados
- O protocolo divide o estado entre estado de gerenciamento de janelas e estado de renderização
- Estado de gerenciamento de janelas: tamanho da janela, modo de tela cheia, foco do teclado, atalhos de teclado etc.
- Estado de renderização: posição das janelas, ordem, decorações, recorte etc.
- As mudanças são processadas agrupadas em atualizações atômicas (manage/render sequence)
- O compositor inicia a sequência e, quando não há mudança de estado, o gerenciador de janelas permanece em espera
- Essa estrutura formaliza explicitamente conceitos que já estavam implícitos no river-classic, sway e outros
Vantagens da arquitetura separada
- Desenvolvedores de gerenciadores de janelas podem focar apenas nas políticas, sem precisar implementar o compositor inteiro
- Depuração e reinicialização são mais fáceis, e uma falha no gerenciador de janelas não encerra a sessão
- Mesmo escrito em linguagens com coleta de lixo, funciona sem perda de desempenho e sem atrasos de quadro
- Já existem mais de 15 gerenciadores de janelas compatíveis com o river, e espera-se uma expansão de diversidade no nível do X11
Limitações e planos futuros
- Atualmente, o protocolo oferece suporte apenas a ambientes de desktop 2D, sem suporte a VR e afins
- Efeitos visuais complexos (por exemplo, janelas tremendo) estão fora do escopo, mas animações simples são possíveis
- Há análise futura para suporte a shaders personalizados, mas isso não está nos planos de curto prazo
- O river 0.4.0 já é suficiente para uso diário, e estão previstas melhorias de UX antes da transição para a versão 1.0.0
- Para continuar o desenvolvimento, há pedido de apoio via liberapay, GitHub Sponsors, Ko-fi
Exemplos e galeria
- São apresentados vários exemplos de gerenciadores de janelas funcionando no river
- Canoe: gerenciador de janelas clássico de empilhamento
- reka: gerenciador de janelas baseado em Emacs
- tarazed: ambiente de desktop focado
- rhine: gerenciamento de janelas recursivo e modular com suporte a animações
- Além desses, existem muitos outros gerenciadores de janelas compatíveis com o river
1 comentários
Comentários no Hacker News
Acho difícil entender as reclamações sobre o Wayland (o protocolo) nos comentários
Bibliotecas como wlroots já cuidaram das partes pesadas, e agora o river oferece abstrações de nível mais alto
O projeto Wayland poderia ter oferecido esse tipo de abstração mais cedo, mas acho que era algo que qualquer um poderia ter feito
No fim, estamos ganhando esses avanços de graça, então não vejo motivo para reclamar porque outra pessoa não fez isso por nós
Questões de acessibilidade também foram tratadas como risco de segurança, o que dificultou o design, e agora que entramos na era da Agentic AI, isso parece um ponto interessante
O PipeWire vem preenchendo lacunas que o Wayland deixou, mas ainda existe a percepção de que falta um design realmente amigável ao usuário
Ainda assim, acho que o Wayland dá um ou dois passos para trás às vezes, mas no geral segue dois passos à frente
Há muita reação no estilo “ou do meu jeito ou vá embora”, com pouca flexibilidade diante de pedidos externos
Ser gratuito é ótimo, mas quando o Xorg é descontinuado e não há alternativa, empurrar isso goela abaixo é problemático
Foi a primeira vez que senti que o Wayland não era perda de tempo ao ver este projeto
Não acho que um servidor de exibição precise necessariamente complicar as coisas gerenciando janelas também
Imagino que o motivo original de o Wayland ter unido gerenciador de janelas e compositor tenha sido simplesmente o caminho de menor resistência
Mas o acesso remoto continua sendo um problema. Coisas que funcionavam bem no X11 tinham muitos bugs no Wayland
O Wayland integrou isso e resolveu a questão, mas criou outros efeitos colaterais
Os limites da API são bem definidos, então compartilhar código é fácil
Fico curioso se o bug de rotação de 90 graus é um problema do compositor ou do wlroots
Acho que só agora começaram a corrigir uma das várias falhas de projeto do Wayland
Deve levar mais uns 15 anos até que protocolos comuns se consolidem e os gerenciadores de janelas amadureçam até o nível do X11
E no fim, provavelmente alguém vai aparecer dizendo que vai “fazer algo melhor”, abandonar o Wayland e começar de novo
Depois de sofrer com problemas de UEFI, acabei migrando para o Samsung DEX
Acho que o limite é menos técnico e mais uma questão política
Como usuário de Linux há 25 anos, estou satisfeito desde que migrei para o Wayland há 5 anos, sem problemas de screen tearing
Para desenvolvedores pode haver mais trabalho, mas para o usuário é claramente uma melhora
Fico pensando se vou continuar falando disso como as pessoas que sentiam saudade dos recursos antigos do CDE
O River já era excelente antes da separação. Estou animado com a evolução daqui para frente
Mudei para o Niri por um tempo, mas pretendo voltar algum dia
Para usuários de Xmonad, o River parece ser a opção mais adequada
Queria saber se no River uma nova janela é inserida acima da janela selecionada no momento
E depois da separação, também queria saber qual é o nome do projeto do lado do gerenciador de janelas
No fim, estamos apenas reinventando os recursos do X11 um por um
Talvez um dia as janelas do Wayland consigam saber sua própria posição
Então provavelmente ainda vai demorar
Os desktops provavelmente ficarão com Android, ChromeOS ou VMs sobre Windows/macOS
Eu uso um gerenciador de janelas River totalmente customizado
No Hyprland, por padrão só dava para usar tiling BSP, o que era inconveniente, mas no River consigo fazer tiling igualitário do jeito que quero
Essa separação mudou bastante meu fluxo de trabalho
Eu também era usuário de i3, e graças ao hy3 consegui usar o Hyprland
Minhas configurações estão organizadas nos dotfiles
Pelo que sei, um dos pontos centrais do design do Wayland era justamente a integração entre gerenciador de janelas e compositor
Fico curioso sobre por que decidiram projetá-lo assim
O Wayland trata isso de forma síncrona para eliminar inconsistências visuais
Este protocolo parece ser uma tentativa de separar servidor gráfico e gerenciador de janelas sem perder essa vantagem de desempenho
Acho que, no Wayland, não poder trocar facilmente um gerenciador de janelas plugável é a maior perda em relação ao X11
Quem está tentando resolver esse problema é realmente valioso
Espero que camadas como River ou Wayback consigam cumprir esse papel
Eu também tenho ideias experimentais para desktop, mas acabo tendo que começar no X11, onde a iteração é rápida
O Wayland ainda tem fraquezas de projeto
Não é necessário que o padrão obrigue uma estrutura específica
Uso i3 há 15 anos e, sempre que surge um projeto assim, volto a me perguntar por que o Wayland é necessário
O X11 tem defeitos, mas dá para fazer quase tudo que eu quero
O Wayland sempre parece trazer muito atrito
Para quem usa notebook isso foi uma grande vantagem, e suporte a VRR ou HDR também é muito mais fácil do que no X.org
Ajuste de DPI por tela, prevenção de screen tearing e bloqueio de gravação de tela não autorizada por apps já vêm resolvidos por padrão
Não precisar mais mexer no Xorg.conf melhorou muito minha qualidade de vida
Até hoje uso proporções de escala diferentes em cada monitor
Eu precisava de uma função que recebesse entrada mesmo com a janela desativada, e só o movimento do mouse funcionava como exceção
No fim mudei para Window Event, mas ainda é inconveniente