- A equipe do Xfce revelou os planos de desenvolver um novo compositor baseado em Wayland, o
xfwl4, com o desenvolvedor principal Brian Tarricone liderando o trabalho com uso de doações da comunidade
- O objetivo é oferecer as mesmas funcionalidades e experiência de uso do
xfwm4, reutilizando a caixa de diálogo de configurações e a configuração do xfconf para garantir continuidade na transição
- Será escrito como um código totalmente novo com base em Rust e no framework smithay, oferecendo segurança de memória e um pipeline personalizado de gráficos e entrada
- O escopo do projeto inclui mudanças na estrutura de gerenciamento de sessão, suporte a XWayland e
xdg-session-management, e melhorias no sistema de build de CI
- Trata-se de um investimento central na transição do Xfce para Wayland, com a primeira release de desenvolvimento prevista ainda este ano
Plano para o novo compositor Wayland do Xfce
- A equipe do Xfce começou o desenvolvimento do novo compositor Wayland
xfwl4 usando doações da comunidade
- O desenvolvimento está a cargo de Brian Tarricone, colaborador central de longa data
- Uma parte significativa do fundo do projeto será usada nesse desenvolvimento
- O objetivo é implementar no ambiente Wayland as mesmas funcionalidades e o mesmo comportamento do
xfwm4
- As caixas de diálogo de configuração do
xfwm4 e as configurações do xfconf serão reutilizadas como estão para manter a consistência da experiência do usuário
- O
xfwl4 não será baseado no código existente do xfwm4 e será reescrito completamente em Rust
- Será construído com base na biblioteca smithay
Por que foi decidido reescrever em vez de reutilizar o código existente
- No início, pensou-se em modificar o código do
xfwm4 para oferecer suporte paralelo a X11 e Wayland, mas isso foi considerado inadequado por vários motivos
- A estrutura do
xfwm4 é dependente de X11, o que dificulta implementar interfaces generalizadas
- Ao refatorar, há alto risco de introduzir bugs no X11
- Existem conceitos do X11 que não são suportados no Wayland, o que tornaria a manutenção do código complexa
- Usar o código existente exigiria dependência de C e
wlroots
- Desenvolver uma base de código separada permite manter a estabilidade do
xfwm4 e avançar em paralelo com o desenvolvimento experimental para Wayland
Por que o smithay foi escolhido
- Brian Tarricone comparou e avaliou
wlroots e smithay antes de escolher o smithay
- O smithay oferece suporte à maioria das extensões oficiais do protocolo Wayland e também a protocolos do
wlroots e do KDE
- Como não há abstrações de alto nível, é possível ter controle detalhado sobre o pipeline de gráficos e entrada
- A documentação é boa e, com o uso de Rust, há redução do risco de bugs relacionados à memória e crashes
- O desenvolvedor prefere Rust
- O
wlroots é escrito em C, o que dificulta a criação de bindings para Rust
Escopo do projeto e desafios técnicos
- Além de alcançar paridade funcional com o
xfwm4, o projeto também inclui as seguintes tarefas
- No ambiente Wayland, o compositor precisa ser a raiz da sessão, então será necessário mudar a estrutura de inicialização da sessão
- Adição de suporte ao protocolo
xdg-session-management
- Inclusão de suporte a XWayland
- Atualização do sistema de build de contêineres de CI para uma base em meson capaz de compilar código Rust
- Brian Tarricone já iniciou o desenvolvimento e a primeira release de desenvolvimento está prevista para este ano
Comunidade e apoio
- O projeto foi viabilizado por doações de apoiadores do Open Collective US e EU
- O andamento do desenvolvimento e os detalhes técnicos podem ser acompanhados nas issues do
xfwl4 e no repositório de código-fonte no GitLab
- Dúvidas relacionadas podem ser feitas pelo canal Matrix
#xfce-dev
1 comentários
Comentários do Hacker News
Ouvi dizer que o xfwl4 busca ter os mesmos recursos e comportamento do xfwm4
Mas, considerando as diferenças estruturais entre X11 e Wayland, fico curioso sobre o quão rígida será essa interpretação de “comportamento”
Por exemplo, a prevenção de roubo de foco no X11 exige heurísticas complexas e verificação de timestamps, enquanto no Wayland o compositor controla completamente o foco
No fim, há o desafio de projetar uma nova política que preserve a sensação das heurísticas antigas, mas se adeque ao modelo de permissões do Wayland
Outro ponto de interesse é a latência causada pela composição obrigatória. Fico me perguntando se, em hardware modesto, será possível obter a mesma responsividade do modo sem composição do X11
A prevenção de roubo de foco pode até ter um comportamento mais consistente no Wayland. O Xfwm4 era baseado em heurísticas e às vezes falhava, mas o modelo xdg-activation do Wayland é bem mais claro
Em termos de desempenho, em hardware moderno não deve haver grande diferença, mas em dispositivos muito antigos isso pode ser um peso. Na prática, acho que só vamos saber com mais testes
A sobrecarga da composição, na prática, é basicamente só o tempo de espera do vsync. Se não for nível Pentium clássico, deve ficar tudo bem
Espero que o XFCE continue sendo um desktop leve
Gosto do KDE, mas é difícil chamá-lo de leve
Vejo tanto o Wayland quanto Rust de forma positiva; o Wayland é a direção do futuro e Rust ajuda a evitar crashes
Só que a base tradicional de usuários do XFCE é conservadora, então pode haver ceticismo com tecnologias novas
A transição para Wayland é inevitável, vai ter um pouco de reclamação, mas deve acontecer sem grandes problemas
Os que insistem em X11 no fim vão virar minoria. Confio na equipe do XFCE
Já existe uma GUI que funciona bem, e o Wayland está criando complexidade desnecessária e problemas de compatibilidade
Protocolos simples tendem a sobreviver por muito tempo, e Wayland vai na direção oposta
O XFCE já é rápido e estável. Se a migração para Wayland o deixar mais lento, ele vai perder sua maior vantagem
Como a comunidade prioriza estabilidade, deve manter o X11 como padrão e só migrar para Wayland quando houver total equivalência funcional
Espero poder continuar usando XFCE quando chegar a hora de migrar para Wayland
Acho que esse projeto em si mostra que o Wayland é a direção certa
O Xorg era uma implementação única, mas o Wayland permitiu o surgimento de vários ecossistemas de bibliotecas (wlroots, Smithay etc.)
Graças a isso, até um projeto de uma pessoa só pode lançar uma prévia para desenvolvedores em poucos meses
Esse tipo de concorrência deve fazer o ecossistema open source evoluir
Mas esse processo foi rápido demais e acabou faltando integração. Acho que vai levar mais uns 10 anos para uma API completa de desktop Linux se consolidar
Acho que a ausência de uma libcompositor foi o maior erro do Wayland
Estou curioso para ver o que a equipe do XFCE vai produzir
A stack é conveniente, mas no fim pode virar uma estrutura difícil de modificar em profundidade
O X funcionava praticamente como um segundo kernel, mas o Wayland aproveita abstrações modernas do kernel como GEM, DMA-BUF e KMS
Isso permite evoluir para uma arquitetura muito mais limpa e eficiente
Uso XFCE como ambiente principal há mais de 10 anos
Fiquei feliz com a notícia do suporte a Wayland
Se for escrito em Rust, isso também pode ajudar a atrair contribuidores
Se quiserem apoio financeiro, recomendo doar para Open Collective e xfce-eu
Acho que a transição de X11 para Wayland é a mudança mais dolorosa da história do Linux
A época do KDE4 também foi um período sombrio
Usei o toolkit cliente em Rust do Smithay, e a segurança de threads não parece completa
Mesmo envolvendo tudo em Arc<>, aparecem crashes estranhos em chamadas multithread
Queria aprender a mergulhar na API do Wayland diretamente e usá-la com segurança
Ainda hoje dá para usar XFCE na maioria dos compositores baseados em wlroots
Eu uso a combinação Hyprland + XFCE no Gentoo
A configuração está neste repositório
Fiquei curioso sobre por que a combinação de Hyprland com XFCE4 foi descrita como uma “combinação amaldiçoada”. Talvez tenha relação com o motivo de o XFCE ter decidido criar o próprio compositor
Eu rejeitava o Wayland, mas mudei de ideia depois de ver o desempenho em hardware antigo
Em um ThinkPad antigo, o Firefox rola muito mais suavemente do que no X11
Os gestos do touchpad também foram adicionados, e isso me agradou. Configurar é um pouco chato, mas é um trade-off que vale a pena
Fico curioso se o Wayland funciona também em sistemas que não são Linux. Por exemplo, seria possível abrir janelas remotas em BSD ou macOS como no XQuartz?
Também existem compositores Wayland para Mac, e o Brodie Robertson publicou um vídeo sobre isso
Pelo projeto WSLg, o Weston renderiza via RDP, o que permite exibir janelas entre plataformas
A aceleração por GPU também é mantida, então acho melhor do que o encaminhamento X11
FreeBSD Handbook Wayland
Hoje em dia, quando dizem “reescrever em Rust”, isso soa como falta de gente para manutenção
Parece que não há quem faça patch no xfwm4, então estão escrevendo outro do zero
Isso também pode ser um sinal de troca geracional — novos desenvolvedores querendo reorganizar tudo com uma estrutura mais simples e segura
Wayland é mais simples que X11, e Rust ajuda a reduzir erros, então é um caminho natural
Mas o custo pode ser sacrificar transparência de rede, desempenho e estabilidade. Aceito isso como o rumo dos tempos