Window Managers: quando o desktop para de tentar pensar por você

Eu entendo quem olha para GNOME, KDE Plasma ou Cinnamon e pensa: “pronto, é isso, esse é o desktop Linux”. Faz sentido. Tem painel, menu, configurações, notificações, gerenciador de arquivos, tema, wallpaper, login bonito e aquela sensação maravilhosa de que alguém já tomou várias decisões por você.

O problema é justamente esse: alguém já tomou várias decisões por você.

Um Window Manager nasce quase como uma resposta mal-humorada a essa ideia. Ele não tenta ser “a experiência completa”. Ele não quer ser seu centro de controle, sua loja de extensões, seu painel de clima, sua dock, sua central de contas online e seu assistente espiritual. Um WM quer resolver uma pergunta muito mais específica:

onde as janelas ficam, como elas se comportam e como você interage com elas?

Parece pouco. Até você perceber que boa parte da sua experiência no computador é exatamente isso.

WM não é Desktop Environment, e essa confusão importa

Um Desktop Environment, ou DE, é um pacote inteiro de experiência gráfica. GNOME, KDE Plasma, XFCE, Cinnamon e LXQt não são apenas “jeitos de mostrar janela”. Eles normalmente entregam um conjunto completo: gerenciador de janelas ou compositor, painel, launcher, configurações gráficas, integração com rede, áudio, energia, temas, sessão, portal de permissões, aplicativos padrão e um monte de serviço que você só lembra que existe quando quebra.

Um Window Manager é bem mais específico. No X11, ele é o componente que decide o posicionamento, foco, decoração, empilhamento e comportamento das janelas. A aplicação pede para aparecer. O servidor X fornece o sistema gráfico. O WM entra no meio e diz: “calma, amigo, você vai abrir aqui, com esse tamanho, nessa área de trabalho e talvez sem essa borda horrorosa”.

No Wayland, a conversa muda um pouco. A figura tradicional do “WM separado” deixa de existir do mesmo jeito, porque o compositor Wayland é o próprio display server. A arquitetura oficial do Wayland descreve justamente essa mudança: no X, o servidor X fica no meio de clientes, compositor e hardware; no Wayland, o compositor recebe eventos do kernel, decide qual superfície deve receber entrada e compõe a tela diretamente. Ou seja: em Wayland, Hyprland, Sway, Niri e Mango não são apenas “window managers” no sentido clássico do X11. Eles são compositores Wayland.

Na prática, a comunidade continua chamando tudo de WM porque linguagem técnica também tem suas preguiças históricas. Mas o detalhe importa. No X11 você podia trocar Openbox por i3, manter Xorg e ainda colocar um compositor como picom por cima. No Wayland, o compositor é a sessão gráfica. Você não “mistura” compositores Wayland como misturava peças no X11. Escolher Hyprland ou Niri é escolher o servidor gráfico daquela sessão.

Isso explica muita coisa: por que suporte a captura de tela, screen sharing, input method, fractional scaling, tablets, NVIDIA e XWayland varia tanto entre compositores Wayland. Não é só “o WM ainda não implementou um detalhe”. Muitas vezes é parte da pilha gráfica inteira.

O X11 venceu porque não tentou ser uma opinião fechada

A história dos WMs no Unix/Linux passa obrigatoriamente pelo X Window System. O X nasceu no MIT em 1984, dentro do contexto do Project Athena, com uma ideia forte: criar um sistema gráfico independente de hardware, rede e fornecedor. A grande sacada do X11 não era ser bonito. Era ser um protocolo.

E como todo protocolo que sobrevive tempo demais, ele virou infraestrutura, legado, piada e milagre ao mesmo tempo. Já comentei sobre.

Um dos princípios mais importantes do X11 era “mechanism, not policy”. A especificação entregava mecanismos para janelas, eventos, desenho, entrada e comunicação, mas não impunha uma política de interface. O X não dizia se uma janela deveria flutuar, ocupar metade da tela, ter borda azul, foco por clique, foco seguindo mouse, barra de título ou botão de minimizar.

Isso abriu espaço para uma explosão de Window Managers. twm, fvwm, Window Maker, Enlightenment, Blackbox, Fluxbox, Openbox, IceWM, AfterStep, Sawfish, Metacity, KWin, Mutter, AwesomeWM, xmonad, dwm, i3, bspwm, herbstluftwm e por aí vai.

O X11 era modular a ponto de permitir combinações absurdas. Às vezes bonitas. Às vezes uma instalação do Arch às 3h da manhã sem áudio, sem barra, sem wallpaper e com um terminal ocupando a tela inteira. Liberdade tem dessas coisas.

Essa flexibilidade também exigiu convenções. O ICCCM, por exemplo, surgiu para definir como clientes X, Window Managers e outros componentes deveriam se comportar entre si. Ele trata de detalhes como foco, estado da janela, ícones, reparenting e comunicação entre clientes. Depois vieram convenções como EWMH/NetWM, usadas para recursos mais modernos de desktop, como áreas de trabalho, painéis, fullscreen, janela urgente e integração com pagers.

Esse é o tipo de detalhe invisível que separa “um programa desenhou uma janela” de “um desktop minimamente utilizável”. O usuário não pensa em ICCCM quando abre um terminal. Ainda bem. Mas o WM pensa, ou pelo menos deveria.

Stacking, tiling e a guerra santa do espaço na tela

O modelo mais familiar é o stacking, ou floating. É o modelo das janelas sobrepostas: você abre um navegador, arrasta para o lado, redimensiona, joga o terminal por cima, perde uma janela atrás de outra, minimiza, maximiza, clica na dock, se arrepende. É o paradigma do desktop como mesa física: janelas como papéis empilhados.

Esse modelo é ótimo para uso geral. Ele é intuitivo, combina com mouse e funciona bem para pessoas que não querem transformar o ato de abrir um programa em uma filosofia de vida.

O tiling parte de outra ideia: janelas não deveriam se sobrepor por padrão. Se você abriu duas janelas, cada uma recebe uma parte da tela. Abriu três, o layout se reorganiza. Abriu dez, talvez você já tenha perdido o controle da sua vida, mas pelo menos o WM tentou manter tudo visível.

Existem variações importantes aqui.

O tiling manual, como no i3, dá bastante controle ao usuário. Você decide dividir horizontalmente, verticalmente, empilhar, tabular, mover para outro workspace. É previsível, mas exige intenção.

O tiling dinâmico, como em dwm, AwesomeWM e Hyprland, trabalha mais com layouts predefinidos. O WM aplica uma estrutura: master/stack, monocle, dwindle, spiral, grid, scrolling e outras invenções que parecem nome de magia em RPG.

O scrolling tiling, como no Niri, é uma ideia mais recente e interessante: em vez de espremer tudo na tela, ele cria uma faixa “infinita” de colunas. Novas janelas entram à direita e as antigas não precisam ser redimensionadas toda vez. É menos “mosaico fixo” e mais “linha do tempo de janelas”.

Essa diferença parece pequena até você usar por alguns dias. Um WM tiling muda seu hábito. Você para de “procurar janela” e começa a organizar contexto. Um workspace para navegador. Outro para código. Outro para terminal. Outro para comunicação. Outro para aquele PDF que você abriu para ler e claramente nunca vai terminar.

O tiling não é novo, só voltou com estética de dotfiles

Existe uma tendência engraçada de tratar tiling WM como coisa moderna, minimalista, de usuário Arch com wallpaper de anime e terminal translúcido. Mas a ideia de janelas em mosaico é antiga.

Interfaces de janelas lado a lado aparecem desde sistemas gráficos dos anos 1980. No mundo X, já havia experimentos de tiling no fim da década de 1980, como o Siemens RTL Tiled Window Manager. Depois vieram décadas de WMs empilhados, ambientes completos e uma certa padronização em torno do desktop “normal”.

A onda moderna dos tiling WMs tem outro gosto. Ela vem da cultura Unix, da preferência por teclado, de configuração textual, de composição com ferramentas pequenas e de um certo cansaço com desktops que tentam resolver tudo com um painel de preferências.

O i3, lançado em 2009, é talvez o melhor exemplo dessa virada para muita gente. Ele não foi o primeiro, nem o mais minimalista, nem o mais academicamente elegante. Mas acertou algo importante: documentação boa, configuração compreensível, árvore de containers, suporte decente a múltiplos monitores e um fluxo que dá para aprender sem compilar o próprio sofrimento.

O dwm foi para outro lado: minimalismo radical, configuração em C, patch em cima de patch e aquela filosofia suckless de “menos é mais”, desde que você aceite recompilar o programa para mudar comportamento. O xmonad trouxe Haskell para a festa, porque aparentemente alguém achou que configurar janelas também precisava de pureza funcional. O AwesomeWM apostou em Lua e extensibilidade. O bspwm separou o WM de forma bem Unix: ele gerencia janelas, você controla via comandos. O herbstluftwm também foi para esse lado de scriptabilidade forte.

Cada um desses WMs é quase uma opinião sobre como o usuário deveria pensar o desktop.

O que muda com Wayland

Wayland não é apenas “o X11 moderno”. Essa frase é confortável, mas incompleta.

No X11, muita coisa era aberta demais. Qualquer cliente podia observar eventos demais, capturar informações demais, interferir demais. Isso era útil para automação, captura, ferramentas de acessibilidade e gambiarras legítimas. Também era ruim para isolamento, segurança e previsibilidade.

Wayland muda a arquitetura. O compositor vira o centro da sessão. Ele recebe entrada, decide foco, gerencia superfícies, compõe buffers e fala diretamente com KMS/DRM no kernel para exibir a tela. Aplicações renderizam em buffers e entregam esses buffers ao compositor.

Isso traz ganhos reais: menos caminhos tortos, melhor modelo de segurança, composição obrigatória, suporte moderno a DPI, frames, tearing control, gestos e uma base mais coerente para o desktop Linux atual.

Mas também traz custo. Coisas que eram “fáceis” no X11 viraram dependentes de protocolos específicos. Screen sharing precisa de xdg-desktop-portal. Captura global de teclado é restrita. Ferramentas de automação precisam de interfaces explícitas. Clipboard, input methods, fractional scaling e color management dependem de maturidade do compositor e dos protocolos.

É mais correto? Sim. É mais chato? Também.

A parte boa é que a nova geração de compositores Wayland está ficando madura. Sway trouxe a proposta de ser um substituto compatível com i3 no Wayland. Hyprland tornou o tiling Wayland visualmente atraente sem pedir desculpa por gostar de animação. Niri está explorando um paradigma diferente com scrolling tiling. Mango tenta pegar a filosofia do dwl/dwm e torná-la mais prática para uso diário.

O Linux desktop sempre foi um laboratório. A diferença é que agora o laboratório tem blur, fractional scaling e bug de portal.

Por que usar um WM em vez de um DE?

A resposta ruim seria: “porque é mais leve”.

É verdade, mas é uma meia verdade meio preguiçosa. Sim, um WM puro costuma consumir menos recursos do que um DE completo. Mas se você instala compositor, barra, launcher, daemon de notificações, polkit agent, wallpaper daemon, applet de rede, gerenciador de clipboard, portal, lockscreen, idle daemon e meia dúzia de scripts, você acabou de montar um DE artesanal. Parabéns, agora o problema é seu.

A razão melhor é controle.

Um WM permite construir um fluxo de trabalho em vez de aceitar um fluxo pronto. Você decide como alternar janelas, como criar workspaces, como mover aplicações entre monitores, qual launcher usar, qual barra exibir, quais atalhos existem, quais janelas flutuam, quais abrem em fullscreen, quais vão para um workspace específico e qual pedaço do sistema deve simplesmente não existir.

Isso é excelente para desenvolvedores, administradores de sistema, usuários de terminal, pessoas com múltiplos monitores, quem trabalha com logs, editores, documentação, navegador e terminal o dia inteiro.

Também é péssimo para quem só quer instalar o sistema e usar.

Essa é a honestidade que muita introdução a WM evita: um WM não é necessariamente “melhor”. Ele é mais explícito. Ele troca conveniência por controle. E controle tem custo.

Você vai configurar coisa boba. Vai descobrir que seu tema GTK não aplica no seletor de arquivos. Vai precisar entender portal. Vai configurar screen sharing. Vai escolher um launcher. Vai se irritar com Electron rodando em XWayland. Vai descobrir que “abrir app no monitor certo” é uma pequena tese de doutorado dependendo do compositor.

Mas quando fica bom, fica muito bom.

Minha ordem atual: Hyprland, Mango, Niri e i3

Eu colocaria minha preferência pessoal hoje nessa ordem: Hyprland, Mango, Niri e i3.

Não é uma lista universal. É uma lista de uso, gosto e tolerância pessoal à gambiarra.

Hyprland: o tiling Wayland que entendeu que estética também importa

Hyprland é provavelmente o compositor Wayland tiling mais chamativo dos últimos anos. E sim, parte disso vem da estética: animações, blur, bordas arredondadas, transições, layouts modernos, screenshots bonitas e aquele apelo de “meu desktop parece uma demo”.

Mas reduzir Hyprland a rice de unixporn é injusto. Ele tem uma combinação forte: tiling dinâmico, configuração rica, regras por janela, IPC via hyprctl, ecossistema próprio e boa integração com utilitários modernos de Wayland. A documentação oficial inclusive deixa claro um ponto que muita gente vindo do X11 ignora: compositor Wayland não deve ser confundido com WM de Xorg. Ele é a sessão gráfica.

O lado ruim é o mesmo de quase todo projeto popular e em movimento rápido: você precisa acompanhar mudanças, ler documentação e aceitar que algumas coisas podem quebrar em atualizações. Hyprland não é a opção mais conservadora. É a opção que eu escolheria para uma máquina pessoal moderna, especialmente se o objetivo for um desktop bonito, rápido e altamente configurável.

É bonito no README e, surpreendentemente, não é triste no dia a dia — desde que você aceite cuidar da própria casa.

Mango: dwm/dwl com mais vontade de ser usável

Mango me interessa por outro motivo. Ele se apresenta como um compositor Wayland rápido e rico em recursos, construído em cima do dwl, com a proposta de manter leveza e adicionar o que torna o compositor utilizável no dia a dia: XWayland, tags, layouts flexíveis, animações, scratchpad, IPC, hot reload de configuração e efeitos.

A ideia é boa porque toca em uma dor real. Projetos minimalistas são lindos até você precisar trabalhar com eles oito horas por dia. A filosofia “faça uma coisa bem feita” vira “faça você mesmo todo o resto” muito rápido.

O Mango tenta ficar num meio-termo: ainda tem cheiro de dwm/dwl, mas não parece tão interessado em transformar cada ajuste em prova de iniciação. Tags em vez de workspaces fixos também são interessantes para quem gosta de um modelo mais flexível de organização.

Eu ainda trataria Mango como uma escolha para quem gosta de mexer. Não é o caminho que eu recomendaria para alguém que acabou de descobrir tiling. Mas para quem já passou por i3, Sway, dwm ou Hyprland e quer algo mais enxuto, com ideias boas e ritmo de projeto novo, faz sentido.

Niri: estranho do jeito certo

Niri é o tipo de projeto que eu respeito porque não está apenas copiando o fluxo de outro WM no Wayland. Ele tenta uma ideia diferente: scrollable tiling.

No Niri, janelas são organizadas em colunas numa faixa horizontal que cresce para a direita. Abrir uma nova janela não força as antigas a encolherem. Cada monitor tem sua própria faixa de janelas, e os workspaces são dinâmicos e organizados verticalmente. Isso muda o modelo mental.

No começo, parece esquisito. Depois você entende a intenção: preservar contexto. Em vez de transformar cada workspace numa competição por pixels, o Niri deixa você navegar por uma sequência de janelas. Para alguns fluxos — logs, documentação, navegador, editor, terminal, múltiplos projetos — isso pode ser excelente.

O custo é reaprender. Se você vem de i3, Hyprland ou Sway, sua memória muscular vai reclamar. O Niri não quer ser só “i3 com scroll”. Ele quer que você pense em janelas como uma faixa contínua. É uma escolha forte, e escolha forte sempre divide opinião.

Eu gosto dele como ideia e como projeto. Talvez não seja meu compositor principal para tudo, mas é um dos WMs/compositores mais interessantes para observar agora. Ele mostra que Wayland não precisa ser apenas “vamos recriar o X11 com nomes novos”.

i3: velho, maduro e ainda difícil de bater como porta de entrada

O i3 continua sendo a recomendação mais fácil para quem quer entender tiling de verdade.

Ele é X11, escrito em C, bem documentado, configurável por arquivo de texto e baseado em uma árvore de containers. O guia oficial explica o básico sem mistério: $mod+Enter abre um terminal, novas janelas dividem o espaço, layouts podem ser split, stacking ou tabbed, workspaces agrupam contextos e tudo pode ser controlado pelo teclado.

O i3 é menos “uau” do que Hyprland. Não tem o mesmo apelo visual. Não é Wayland. Não é novidade. Mas isso também é uma qualidade. Ele é previsível, estável, pesquisável e cheio de exemplos. Se você quer aprender o conceito sem brigar com metade da stack Wayland, i3 ainda é excelente.

Eu não colocaria i3 como minha primeira escolha hoje para uma instalação nova em hardware moderno, principalmente porque Wayland já faz mais sentido para muita coisa. Mas como escola de tiling WM, ele continua ótimo. É o tipo de ferramenta que talvez você substitua depois, mas dificilmente se arrepende de ter aprendido.

O que um DE ainda faz melhor

Existe um certo teatro em comunidades Linux de fingir que usar WM puro é uma forma superior de existência. Não é.

DEs resolvem problemas reais. GNOME e KDE Plasma entregam integração. Eles cuidam de portal, sessão, configurações, acessibilidade, temas, input methods, notificações, energia, Bluetooth, rede, monitores, touchpad, permissões e aplicativos padrão. Você perde controle fino, mas ganha coerência.

Para notebook, usuário comum, ambiente corporativo, máquina compartilhada ou pessoa que não quer transformar o desktop em hobby, um DE é muitas vezes a escolha correta.

WMs brilham quando o computador é ferramenta de trabalho técnico e você quer moldar a interface ao seu fluxo. DEs brilham quando o ambiente precisa simplesmente funcionar com menos manutenção manual.

A diferença não é “leve versus pesado”. A diferença é produto versus kit.

Um DE é um produto. Um WM é uma caixa de peças. Quem gosta de montar a própria bancada vai amar. Quem só queria uma mesa para colocar o notebook vai achar uma doença.

O mínimo que você precisa saber antes de migrar

Se você vai sair de um DE para um WM, vá com a expectativa certa. O WM não vai trazer tudo.

Você provavelmente vai precisar escolher:

• uma barra, como Waybar, i3bar, polybar ou similar;
• um launcher, como rofi, wofi, fuzzel ou dmenu;
• um terminal;
• um daemon de notificações;
• um gerenciador de wallpaper;
• um lockscreen;
• um polkit agent;
• um clipboard manager;
• ferramentas para screenshot e gravação;
• portal para screen sharing, especialmente em Wayland.

Isso parece uma lista chata porque é uma lista chata. Mas ela revela algo importante: um desktop não é só janela. Desktop é integração.

Quando alguém mostra um setup lindo de Hyprland, Niri ou i3, aquilo não é só o WM. É um conjunto de escolhas: tema GTK, fonte, terminal, shell, barra, launcher, atalhos, scripts, wallpaper, compositor, portal, clipboard, notificações e provavelmente umas três gambiarras que o autor esqueceu que fez.

Por isso, a pergunta certa não é “qual WM é melhor?”. A pergunta certa é:

qual quantidade de controle eu quero assumir?

Se a resposta for “pouca”, use KDE ou GNOME e seja feliz. Se a resposta for “muita”, bem-vindo. Tem um arquivo de configuração esperando para estragar sua noite.

WMs são uma aula prática de arquitetura

A melhor parte de usar Window Managers não é ganhar 200 MB de RAM. Isso é troféu de benchmark de fórum.

A melhor parte é entender a arquitetura do desktop.

Você aprende que janela não é só janela. Existe display server, compositor, protocolo, buffer, evento de input, foco, workspace, regra, portal, XWayland, clipboard, sessão, monitor, scaling, renderização e um monte de contrato implícito entre aplicação e ambiente gráfico.

Você começa a entender por que screen sharing quebra. Por que Electron às vezes abre em XWayland. Por que tema não aplica em todo lugar. Por que Wayland é mais seguro, mas às vezes mais irritante. Por que X11 era flexível, mas flexível daquele jeito que também permite amarrar tomada com fita isolante.

Um WM te força a olhar para a pilha. E isso, para quem gosta de Linux, é quase inevitável. Usar Linux por tempo suficiente é descobrir que “interface gráfica” não é uma coisa. É um acordo de paz temporário entre vários programas que discordam em silêncio.

Então, por onde começar?

Se você nunca usou tiling WM, eu começaria pelo i3 ou pelo Sway. O i3 ensina o modelo clássico no X11. O Sway te dá uma experiência parecida no Wayland. Ambos têm documentação boa e comportamento previsível.

Se você já entende o básico e quer um desktop moderno, eu iria de Hyprland. É o que eu recomendo para quem quer Wayland, tiling dinâmico, visual forte e bastante material de comunidade.

Se você gosta de projetos mais enxutos e quer algo com cara de dwm/dwl, mas mais prático, Mango é uma opção interessante para testar.

Se você quer experimentar um paradigma diferente de verdade, Niri é o nome. Talvez você ame. Talvez odeie. Mas pelo menos vai sair com uma opinião, e isso já é mais do que muito software genérico consegue provocar.

O importante é não tratar WM como religião. Use o que melhora seu fluxo. Troque quando parar de fazer sentido. Copie dotfiles com vergonha moderada. Leia documentação. Faça backup da config. E lembre que um desktop bonito não vale muita coisa se você precisa lutar com ele toda manhã.

Window Managers não são melhores por definição. Eles só são mais honestos sobre o custo da liberdade.

Um DE te entrega uma casa mobiliada. Um WM te entrega o terreno, umas ferramentas e a liberdade de colocar a porta no teto.

Às vezes é exatamente isso que você queria.