O Budgie 10.10 é a versão final da série 10, focada em entregar uma sessão Wayland pronta para uso diário (compositor Labwc, applets portados, serviços renovados) e, ao mesmo tempo, liberar a equipe para a re-arquitetura do Budgie 11 em Qt6.
Detalhes da versão: jan 2026 | Status: estável | Série 10: modo manutenção | Próxima geração: Budgie 11 (Qt6)
Destaques técnicos
- Wayland nativo com integração reforçada ao Labwc e ajustes de UX ao longo de 2025
- Applets críticos portados e corrigidos, com foco em paridade funcional com X11
- Screenshot refeito com Grim e Slurp
- Bloqueio de tela e idle reestruturados com Swayidle, Gtklock (ou Swaylock) e Wlopm
- Budgie Desktop Services (budgie-daemon v2) em Qt6, já assumindo peças importantes no Budgie 10.10
- Repositórios de futuro desenvolvimento movendo-se do GitHub para Forgejo, com CI/CD próprio via Woodpecker
O fim de uma era: Budgie 10.10 e Wayland
A equipe descreve 2025 como o ano em que o projeto consolidou a migração para Wayland, indo além do “funciona no dia a dia” e chegando ao nível de polimento e coerência necessário para declarar o Budgie 10.10 como a culminação da série 10. A versão estava planejada para 2025, mas o atraso virou vantagem: mais tempo para testar, reescrever trechos antigos e, principalmente, “colar” ferramentas Wayland consolidadas em um fluxo de uso mais consistente.
🛠️ Stack técnica: no Budgie 10.10, a base Wayland se apoia no compositor Labwc (padrão), com utilitários como Grim/Slurp (captura), Gammastep (night light via protocolo de controle de gamma), e um conjunto novo de peças para idle e bloqueio de tela (Swayidle, Gtklock/Swaylock, Wlopm). Parte do “cérebro de serviços” passa pelo Budgie Desktop Services (Qt6).
Portabilidade de applets: o que foi resolvido em 2025
Vários applets precisaram de cirurgia para reduzir dependências do X11 e atingir paridade de recursos:
- Night Light applet: passou a usar o protocolo wlr gamma control via gammastep.
- Workspace applet: corrigido para Wayland, removendo dependência de IDs de janela do X11 e lidando melhor com janelas sem app associada logo no início da sessão.
- Keyboard Layout applet: ganhou suporte a mudança por janela e XKB_OPTIONS, mas ficou desativado no Budgie 10.10 para mais testes, com retorno esperado em um 10.10.x.
- Icon Tasklist: correções em agrupamento de janelas no Wayland, removendo funcionalidades específicas do X11.
- Tasklist: um dos últimos a migrar e um dos mais complexos, recebeu reescrita completa e passou a usar libxfce4windowing.
Screenshots: adeus dependência específica do Mutter
No Wayland, a abordagem tradicional de captura muda bastante. O Budgie reescreveu o sistema de screenshot para abandonar código específico do Mutter e adotar grim (captura) e slurp (seleção de região). O diálogo de captura foi movido para o controle do budgie-session e reforçado para lidar com cenários em que detalhes do cliente Wayland ainda não estão disponíveis no início da sessão.
Sessão e login: menos improviso, mais previsibilidade
Entrou um modelo de inicialização mais robusto para sessão Wayland, incluindo um script de start que:
- define variáveis de ambiente,
- copia configurações para o diretório correto do usuário,
- inicia o compositor Wayland, com labwc como padrão,
o que reduz fricção na tela de login e torna o comportamento mais determinístico em diferentes distros.
labwc bridge: configura no Budgie, aplica no compositor
Uma peça-chave para o “Wayland maduro” é o labwc bridge, um mecanismo de sincronização (unidirecional) que replica mudanças do Budgie Control Center para o labwc, cobrindo atalhos de teclado, mouse e touchpad e outros pontos de configuração. Na prática, isso elimina a necessidade de ajustes manuais no compositor e aproxima a experiência do que usuários esperam em um desktop integrado.
Bloqueio de tela e idle: finalmente, uma troca necessária
O Budgie 10.10 fecha uma ferida antiga removendo o budgie-screensaver (fork do gnome-screensaver) e substituindo por uma stack Wayland mais apropriada: swayidle para idle, gtklock (ou swaylock) para lock e wlopm para gerenciamento de energia da tela. É o tipo de mudança que não chama atenção quando dá certo, o que é exatamente o objetivo.
girepository-2.0: mudança de base que exigiu disciplina de ABI
A migração do Budgie Desktop para girepository-2.0 foi descrita como um “wrench in our plans”, porque exigiu ajuste de ABI, um lançamento Budgie 10.9.x e coordenação com parceiros (como Ubuntu Budgie) para manter compatibilidade de applets. É um detalhe que não rende manchete, mas explica por que o 10.10 “precisou cozinhar” mais do que o previsto.
Antes vs agora: X11 vs Wayland no Budgie 10.10
Antes (X11 no Budgie 10.x):
- applets e tasklists dependiam de conceitos como IDs de janela e caminhos específicos do X11
- captura de tela apoiada em implementações específicas do compositor
- lock screen e idle presos a um legado problemático (budgie-screensaver)
- integração com compositor fora do Budgie exigia mais configuração manual
Agora (Wayland no Budgie 10.10):
- applets reescritos para protocolos Wayland e para cenários reais de sessão Wayland
- captura com Grim/Slurp, e controle do fluxo pelo budgie-session
- lock/idle com Swayidle + Gtklock/Swaylock + Wlopm
- sincronização automática de configurações com labwc bridge
- notificações e OSD reestruturados para comportamento consistente via layer-shell
⚖️ Veredito: o Budgie 10.10 entrega uma sessão Wayland que parece “nativa” porque resolveu o que mais dói no dia a dia: applets críticos, consistência de notificações/OSD, captura de tela, login previsível e lock/idle que não herda problemas do passado. Ao colocar a série 10 em manutenção, o projeto sinaliza que, a partir daqui, o esforço incremental vira correção e estabilidade, não mudança estrutural.
Budgie 11: a revolução Qt6
A escolha de toolkit para o Budgie 11 virou, por anos, um folclore de comunidade. Desta vez, a declaração vem com algo que faltava em anúncios anteriores: código funcional já rodando em produção. O projeto confirma que Budgie 11 será Qt6, e o argumento mais forte é que parte do futuro já está em operação no presente.
⚠️ Mudança de rota: o Budgie 11 troca a base principal para Qt6. A promessa não é só “portar telas”, e sim re-arquitetar o desktop para modularidade, múltiplos form factors e melhor integração com o ecossistema.
O que já é Qt6 hoje, dentro do Budgie 10.10
O texto do lançamento é direto: Budgie Desktop Services (budgie-daemon v2), escrito em Qt6, é “o coração” do Budgie 11 e já assume funções relevantes no Budgie 10.10, como:
- gerenciamento de saída de vídeo em Wayland,
- persistência de configuração via “shim mode”,
- armazenamento de estado em arquivo TOML,
- integração com wdisplays para configuração gráfica.
Para o Budgie 11, o plano é emparelhar isso com um configurador de displays próprio (em alguma forma), também em Qt6 e Kirigami.
Re-arquitetura: Budgie Core vs Budgie Desktop
Aqui está a maior mudança de mentalidade do projeto: Budgie 11 não quer ser só “um desktop”, quer ser uma plataforma.
- Budgie Core (Budgie como plataforma):
- bibliotecas compartilhadas para todos os alvos,
- Session Manager gerenciando ciclo de vida de apps e serviços,
- Budgie Services provendo notificação, displays, idle e outros, expostos via DBus (e possivelmente outros RPC/serializações),
- bibliotecas suplementares para energia, locale, input e configuração.
- Budgie Desktop (Budgie como desktop):
Um “presentation layer” focado em desktops, laptops e 2-in-1, com três atributos prioritários:- adaptável (multitarefa, gestão de janelas e workspaces, tiling, modos como foco e games),
- aproximável (curva de aprendizado curta, coerente com a filosofia do 10.x),
- extensível (customização por usuários e por distros).
O Budgie 11 precisa facilitar:
- troca de componentes (por exemplo, compositor, Raven ou alternativas de notificações),
- troca de extensões (painéis e Raven),
- theming mais flexível, inclusive com ambição “cross-platform” quando possível,
- um caminho mais centralizado para distribuição e descoberta de extensões, com possibilidade de extensões em QML e JS.
Lições do Budgie 10 que moldam o Budgie 11
O texto aponta dores concretas que o Budgie 11 quer evitar:
- acoplamento excessivo no repositório budgie-desktop (shell, painel, Raven, configurações), com complexidade adicional herdada do mundo X11;
- modelo de plugin e empacotamento: embora libpeas tenha sido excelente para pluggability, cada distro acabou carregando o fardo de empacotar e manter applets de terceiros, e a descoberta desses applets virou um problema crônico;
- gestão de sessão convoluta em budgie-session e budgie-desktop, com subutilização do systemd e pouco aproveitamento de serviços em nível de usuário, mantendo abertura para init alternativo.
Adeus GitHub, olá Forgejo
O projeto coloca em termos bem pragmáticos: GitHub foi uma escolha óbvia no passado pelo efeito de rede, mas passou a “caber mal” para as necessidades do Budgie. O gatilho mais recente foi o aumento de “AI slop”, incluindo issues geradas por Copilot, que aumentaram o custo de triagem para o time.
A decisão então foi clara:
- desenvolvimento futuro de componentes do Budgie 11 migra para um forge próprio em Forgejo (self-hosted), em uso desde maio,
- o GitHub continua como casa do Budgie 10.10, que entra em modo manutenção.
CI/CD próprio: Woodpecker e foco em multi-arquitetura desde o começo
Com a troca de forge, a equipe também precisava de validação de mudanças. O plano em andamento:
- pipeline via Woodpecker em ci.moderndesktop.dev,
- builder dedicado ARM64 (multi-arquitetura “by design”),
- preparação de hardware dedicado para testes gráficos (primeiro x86_64, depois RISC-V RVA23 quando disponível),
- ambição de incorporar testes tipo OpenQA e uma esteira clara:
Code change → CI → geração de RPM → geração de ISO → testes OpenQA → testes manuais do time → distribuição (incluindo early access para apoiadores do OpenCollective)
O que esperar em 2026
Além de “mais código”, o que o texto sugere é uma execução com mais previsibilidade técnica: versionamento, ABI e arquitetura publicados de forma mais transparente assim que um conjunto inicial de especificações estiver maduro.
Versionamento X.Y.Z e estabilidade de ABI
A proposta para Budgie 11 quebra X.Y.Z em:
- X (major): travado ao major do Qt. Budgie 11 = Qt6, Budgie 12 = Qt7, etc.
- Y (feature): incremento semestral alinhando todos os componentes, com possibilidade (não obrigação) de quebra de ABI em releases de feature. A ideia é suportar ABIs no intervalo N-3..N, com vida útil de ABI em torno de 2 anos, alinhado ao Ubuntu LTS, e possibilidade de estender o primeiro ABI do Budgie 11 para 3 anos.
- Z (patch): bugfixes e pequenas melhorias.
Comunicação: “Chirps” para reduzir buracos de informação
A equipe reconhece que posts longos viraram gargalo e que a comunicação sofreu, inclusive em torno do Budgie 10.10. A resposta proposta é um formato de updates menores e mais frequentes, os Chirps, para complementar posts grandes, com distribuição automática em redes sociais e para apoiadores do OpenCollective.
FAQ
O Budgie 10.10 funciona bem no Wayland?
A intenção do lançamento é exatamente essa: consolidar uma sessão Wayland “coesa”, com applets críticos portados, captura de tela reescrita (Grim/Slurp), notificações e OSD ajustados para layer-shell, e uma solução moderna de idle e lock screen. O próprio projeto descreve a experiência de janeiro de 2026 como “significativamente melhor” do que no início de 2025.
Quando sai o Budgie 11?
Não há data fechada no texto. O que existe é um kickoff técnico já em andamento em 2026, com decisões sobre arquitetura, estrutura de repositórios, versionamento e garantias de ABI sendo definidas agora. A leitura prática é: a base já está sendo construída, mas o cronograma público depende da maturação dessas especificações.
O Budgie vai deixar de parecer com o GNOME?
O texto não promete uma ruptura estética imediata, mas deixa claro o objetivo de modularidade e independência estrutural, incluindo foco em um “Budgie Core” e em “Budgie Desktop” como camada de apresentação, com maior capacidade de troca de componentes e extensões. Isso abre espaço para distros e usuários criarem experiências mais distintas ao longo do tempo.
Como eu confirmo que estou em Wayland no Budgie 10.10?
Em distros que já empacotam o Budgie 10.10 com sessão Wayland, você pode validar rapidamente pelo tipo de sessão e pelo compositor:
# Confirma o tipo de sessão echo "$XDG_SESSION_TYPE" # Mostra detalhes da sessão atual (systemd-logind) loginctl show-session "$XDG_SESSION_ID" -p Type -p Name -p Remote