XFCE 4.20 mira suporte preliminar ao Wayland
(ostechnix.com)- O XFCE 4.20 está sendo preparado como uma versão de transição que mantém seu ponto forte tradicional como ambiente de desktop X11 leve, ao mesmo tempo em que adiciona suporte inicial ao Wayland aos componentes principais
- A adoção do Wayland deve trazer melhorias de desempenho e segurança, menor latência de entrada e suporte a HiDPI, graças a uma estrutura de exibição mais simples e à comunicação direta
- O escopo inicial de suporte começa com xfce4-panel, xfdesktop, libxfce4ui e xfce4-settings, enquanto o port e os ajustes de compatibilidade seguem em andamento por componente
- No entanto, ainda faltam o desenvolvimento do xfwm4 para Wayland e a adaptação de plugins do painel e aplicativos, então o cronograma de uma sessão XFCE Wayland completa ainda não está definido
- A direção do desenvolvimento parece estar mais próxima de permitir que os usuários testem opcionalmente o Wayland enquanto mantêm o ambiente XFCE com o qual já estão acostumados, em vez de abandonar o X11
Escopo da transição para Wayland no XFCE 4.20
- O XFCE 4.20 tem como objetivo introduzir suporte inicial ao Wayland nos componentes principais
- O XFCE tradicionalmente é conhecido como um ambiente de desktop X11 leve e personalizável, e a versão 4.20 adiciona Wayland mantendo a compatibilidade com X11
- Os usuários poderão continuar usando a experiência tradicional do XFCE enquanto testam o ambiente Wayland
-
O que o Wayland muda
- O Wayland é um protocolo moderno de servidor de exibição projetado para substituir o antigo sistema X11
- Sua estrutura mais simples e a comunicação direta entre aplicativo e servidor de exibição tornam os gráficos mais suaves, reduzem a latência de entrada e melhoram a segurança
- O suporte nativo a telas de alta resolução oferece imagem mais nítida em hardware moderno
- Ele usa uma abordagem centrada no compositor, na qual o compositor controla de forma mais eficiente o gerenciamento de janelas, animações e efeitos
Andamento por componente e trabalho restante
-
Componentes principais
- O xfce4-panel foi ajustado para o Wayland usando o framework de compositor wlroots e está sendo preparado para funcionar nesse ambiente
- O xfdesktop foi portado para Wayland, e o suporte a recursos como áreas de trabalho e lista de janelas continua em desenvolvimento
- O libxfce4ui foi atualizado para garantir compatibilidade tanto com X11 quanto com Wayland
- O xfce4-settings recebeu componentes compatíveis com Wayland, e as configurações de exibição foram ajustadas para funcionar separadamente em X11 e Wayland
-
Desafios que ainda restam
- Ainda falta o desenvolvimento do xfwm4 para Wayland
- Vários plugins do painel e aplicativos também precisam de trabalho de suporte ao Wayland
- O objetivo de longo prazo é oferecer uma sessão XFCE Wayland completa, mas o cronograma exato ainda é incerto
Cronograma de lançamento do XFCE 4.20
- O plano atual de lançamento do XFCE 4.20 é o seguinte
- 1 de novembro de 2024: XFCE 4.20pre1, congelamento de recursos e strings
- 1 de dezembro de 2024: XFCE 4.20pre2, congelamento de código
- 15 de dezembro de 2024: XFCE 4.20pre3, congelamento final, lançamento opcional
- 15 de dezembro de 2024: lançamento final previsto do XFCE 4.20; se houver pre3, em torno de 29 de dezembro de 2024
- Material de referência: https://wiki.xfce.org/releng/4.20/roadmap
1 comentários
Comentários no Hacker News
Para deixar claro, ainda não existe um compositor
Já mexemos um pouco nisso, mas provavelmente vai levar no mínimo 1 ano, talvez mais, até ficar utilizável
No 4.20, alguns componentes poderão rodar sobre outros compositores, e nosso compositor também deve usar wlroots, então os testes estão sendo feitos principalmente com Wayfire e Labwc
Só fico curioso para ver como as pessoas vão reagir a essa mudança. Entre os usuários do XFCE, há muitos que querem Wayland ou não se importam, mas também parece haver muita gente que vai resistir fortemente a isso
Indo devagar, parece possível lapidar o XFCE no Wayland para aproveitar os benefícios do crescimento recente do Wayland e ao mesmo tempo minimizar os problemas da transição
Eles também estão criando um compositor Wayland para desktop cada vez menos baseado em GTK e já estão num estágio bem avançado, então talvez esse compositor atenda aos requisitos
Aliás, gosto muito do XFCE. Acho perfeito o equilíbrio entre recursos, estabilidade e desempenho
Seria bom evitar repetir a bagunça de bilhões de bibliotecas X11 espalhadas por todo lado
No lado Linux/BSD, se você quer um gerenciador de janelas leve e que funcione de cara sem precisar fuçar configurações, sinceramente sinto que o XFCE é a única opção realmente prática
É como uma versão melhor da interface do Windows 2000, com padrões razoáveis no geral. Sou muito grato aos desenvolvedores que continuam mantendo o XFCE atualizado, e essa notícia é excelente
Por isso acabei descobrindo que o Cinnamon também é uma opção bem boa de “interface melhor que a do Windows 2000”
O Cinnamon também não é perfeito em HiDPI, mas quando você aumenta a fonte para 150% ou 200%, o sistema inteiro não desanda. No XFCE, quando faço isso, tudo fica feio
Uso XFCE todos os dias, especialmente em dias de trabalho
Uso há anos, desde a época em que era o único gerenciador de janelas que conseguia rodar sem travar num netbook baseado em Atom. Na época, aquele era o único “PC” que eu tinha
Muito tempo depois, ainda uso e continuo satisfeito. Não sei se as pessoas sabem como é clicar em algo e ele responder imediatamente, sem atraso
É um software excelente, e sou grato a todos os desenvolvedores que trabalham nele
Vi algumas reclamações sobre HiDPI; não sei se ajuda, mas uso uma tela 4K de notebook, um monitor 4K ligado por USB-C e um monitor em modo retrato com resolução 1024 via HDMI
Se eu definir x2 nas configurações de aparência, os dois monitores 4K ficam muito bonitos, e se eu definir escala 2x também para o monitor 1024 no gerenciador de telas, ele fica aceitável. Claro, não fica tão bom quanto os 4K, mas isso também porque o monitor em si já é pior, e sinceramente até me surpreende funcionar tão bem
Há alguns meses, quando instalei Linux no computador do trabalho, o fato de o XFCE estar preso ao X11 foi o que finalmente me levou a migrar para o KDE
Ao compilar código numa máquina remota, um terminal numa janela fazia o vídeo do YouTube em outra janela engasgar. Pelo que verifiquei, parecia não haver aceleração por hardware na reprodução
Parecia que tanto o Chrome quanto o Firefox estavam praticamente abandonando o X11 e indo para Wayland com backends de renderização baseados em Vulkan
Depois de deixar o KDE 5 “cozinhar” durante a noite — uso Gentoo, então compilar um ambiente de desktop completo como o KDE leva tempo — tudo simplesmente funcionou
Sinto falta da simplicidade visual do XFCE e quero voltar algum dia, mas por enquanto a responsividade é o principal
Sempre prefiro software leve e que consuma menos recursos, mas dá para dizer que não usar aceleração por hardware acaba consumindo ainda mais recursos
Alguns anos atrás eu usava bastante dwm e gostava, mas quando preciso montar um ambiente rapidamente normalmente volto para o Xfce
Os computadores da família, os PCs do meu pai, da minha mãe, da minha irmã e até o PC de mídia que deixei assim por preguiça, todos usam Xfce. Se o Xfce passar a oferecer suporte a Wayland, acho que vou considerar a mudança
Ainda lembro de ter visto um vídeo do que acho que era o Xfce 4.0.4, e de ter ficado impressionado com como era simples e estável poder escolher diretamente os lançadores e widgets na barra. Era muito mais simples que o Gnome da época
O KDE moderno às vezes até me parece com o Xfce, mas quando tento mexer nas configurações encontro muitos bugs estranhos. O Xfce também já teve problemas assim, como na época em que o Thunar era bem instável, mas ainda é o desktop para o qual volto pela simplicidade e estabilidade
O motivo é que todos cresceram com o Win9x, e a metáfora visual do XFCE é imediatamente compreensível para eles. Desde que YouTube e Facebook funcionem, eles não ligam nem um pouco para o que tem por dentro
Aliás, o dwm é excelente. Como quase tudo do pessoal do suckless
Sinceramente, o compartilhamento de tela do Wayland e outras partes ainda são frágeis demais, então o fato de o XFCE, que uso no dia a dia, estar atrasado nessa adoção até parece uma vantagem
No começo estava totalmente quebrado, e parecia bem ruim porque era preciso adicionar suporte explícito em cada aplicativo, mas recentemente não tive problemas com Firefox, Zoom e Slack
A única exceção é o Microsoft Teams, em que nem a webcam funciona direito
Quando mandaram todo mundo para casa por causa do lockdown, o compartilhamento de tela não funcionava por padrão no MS Teams no Chrome, mas depois de alguns minutos pesquisando encontrei a flag do Chrome que precisava ativar e criei um novo arquivo desktop local para iniciar com a flag correta
Depois disso, o que faltava era basicamente suporte a HDR e correção de cores. É uma pena que ainda não esteja pronto, mas como pouquíssimas pessoas realmente usam isso, para 99,9% dos usuários o Wayland funciona bem
Nem sei se dá para compartilhar janela individual ou aba
Fico curioso para saber como isso está no lado do Wayland
A transição para Wayland parece vir junto com a adoção de decorações do lado do cliente
Essa abordagem “moderna” destrói a experiência de usuário tradicional do XFCE, como ficou visível nas mudanças recentes no gerenciador de configurações. Fico preocupado com o futuro do XFCE
Para mim, o ponto forte do XFCE sempre foi oferecer de forma estável uma experiência de usuário tradicional no estilo Win98/XP. Espero que ele não adote mais padrões do Gnome3
A transição para Wayland e as decorações do lado do cliente não têm muito a ver uma com a outra
O lado GNOME/GTK já estava nessa onda de CSD antes mesmo do Wayland. Um compositor Wayland pode desenhar sua própria decoração, e o xfwm4 deve continuar fazendo isso quando virar um compositor Wayland
Uma das coisas realmente boas do Wayland é que existe um protocolo pelo qual o compositor pode dizer ao aplicativo para não desenhar a própria decoração. Já no X11, se o aplicativo disser ao gerenciador de janelas que vai desenhar CSD, o gerenciador não pode fazer nada
O GNOME realmente foi até o fim com CSD e, se não me engano, no GNOME, se o aplicativo não desenhar CSD, ele fica sem decoração nenhuma, mas isso não tem relação com Wayland
Não entendo o que isso tem a ver com Wayland ou com XFCE. Na prática, o único grande ambiente de desktop que usa decorações do lado do cliente é o GNOME, e isso é assim desde 2018
Fonte: https://blog.martin-graesslin.com/blog/2018/01/server-side-d...
O Wayland é neutro; como isso vai funcionar nele é algo a ser decidido pelo compositor e pelo aplicativo
CSD não tem relação com experiência de usuário. CSD só significa que o aplicativo desenha seus próprios botões e bordas de janela
Meus requisitos de acessibilidade estão praticamente mortos no Wayland
Eu preciso de atalhos de teclado imitáveis por aplicativo e de atalhos globais
Mas o modelo de segurança do Wayland parece não permitir isso. Não sei como ferramentas de acessibilidade e automação vão sobreviver se tiverem de oferecer suporte a todos os compositores Wayland
O resto pode ficar nas bibliotecas e toolkits, mas o ponto de integração provavelmente precisa estar no compositor
https://github.com/rvaiya/keyd
Em comparação com o Windows, ele fica tão atrás em acessibilidade que nem tem graça
Estou entendendo certo que a ideia é construir em cima do wlroots?
Se for isso, é um avanço bem-vindo. Porque aí talvez dê para aproveitar a robustez dos apps do XFCE em outros gerenciadores de janelas/compositores, como Sway ou River
Já mexi um pouco no trabalho do xfwm4 usando wlroots, mas ainda deve levar mais de um ano para ficar utilizável
Os componentes de desktop que funcionam no Wayland foram testados principalmente em compositores baseados em wlroots
Se eu tivesse de usar um ambiente de desktop no Linux, usaria XFCE
Mas essa onda do Wayland está me empurrando mais para o lado do BSD. Ainda não abandonei o Linux, e acho que o Wayland não vai se tornar obrigatório até o Firefox deixar de oferecer suporte a X
Só que ainda não descobri a combinação mágica de comandos dbus necessária para fazer o compartilhamento de tela funcionar sem systemd. Pelo menos pipewire parece ser necessário