Uma peculiaridade do X Window System: janelas até o fim

Artigo original ↗ Discussão no Hacker News ↗

Interfaces gráficas do X11 ao Microsoft Windows e ao Mac OS clássico há muito tratam quase todo elemento na tela — botões, caixas de texto, barras de título — como um tipo de “janela” ou view, cada um com suas próprias coordenadas, eventos e contexto de desenho. Os comentários comparam como diferentes sistemas implementam essa hierarquia (controles nativos vs “sem janela”, decorações do lado do cliente vs do servidor, limites globais de handles e captura de entrada) e como essas escolhas afetam desempenho, skinning, exibição remota e acessibilidade. O tema geral é que esse modelo de janela até o fim é historicamente comum e conceitualmente elegante, mas precisou evoluir ou ser parcialmente abandonado à medida que as UIs ficaram mais ricas e complexas.

Janela-como-primitiva-universal

  • Muitos sistemas GUI fazem “tudo é uma janela/view”: X, Microsoft Windows (HWND), GTK, Qt, as views clássicas do Smalltalk e, em certa medida, o Mac clássico (janelas mais controles mais leves).
  • Desenvolvedores observam que isso muitas vezes “surge naturalmente” ao implementar uma GUI: tudo tem posição, limites, desenho e filhos, então “janela até o fim” é uma arquitetura comum, não algo exclusivo do X.
  • Alguns defendem separar conceitos (por exemplo, janelas vs controles) mesmo que compartilhem implementação, para manter o modelo mental mais limpo.

Desempenho, Recursos e Controles sem Janela

  • Sistemas antigos usavam muitas janelas reais para controles sem grandes problemas de desempenho, mas atingiam limites de recursos (heaps GDI/USER de 16 bits, máximos de handles).
  • À medida que as UIs ficaram mais ricas (navegadores, apps com skins, transparência, imagens complexas), janelas por controle passaram a ser pesadas demais; isso motivou “windowless controls” e os “alien widgets” do Qt.
  • Até toolkits modernos como o Qt tornam listas pesadas em QWidget lentas; desenho customizado mais tratamento de eventos para itens de lista escala melhor.
  • No Windows, o GDI costumava desenhar diretamente na VRAM; com o Desktop Window Manager, as janelas agora são texturas compostas, mais próximas da história moderna de composição do X.

Áreas de Cliente vs Não Cliente e Decorações

  • O Windows clássico distingue áreas de cliente e não cliente (barra de título, bordas, botões), cada uma com mensagens separadas; normalmente os apps deixam os padrões tratarem a área não cliente.
  • O Presentation Manager do OS/2 tratava tudo, inclusive a área de cliente, como janelas-filhas, simplificando o modelo com possível custo de velocidade.
  • O tratamento da área não cliente ajuda a manter mover/fechar janelas responsivo mesmo quando os apps estão ocupados ou travados; alguns comparam isso favoravelmente às decorações do lado do cliente no Linux/Wayland, onde apps congelados podem ser mais difíceis de gerenciar.
  • Há discordância contínua sobre decorações do lado do cliente: alguns valorizam consistência por meio de molduras do lado do servidor; outros observam que apps projetados para CSD (por exemplo, alguns apps Linux) ficam melhores assim.

Modelo Cliente/Servidor do X e Terminologia

  • Vários comentários defendem que o “servidor” do X é o sistema de display e os “clientes” são os apps: é análogo a servidores de arquivos/impressão/banco de dados mediando acesso a um recurso.
  • A confusão vem principalmente do marketing de “computação cliente-servidor” dos anos 1990 e de modelos mentais centrados no usuário, em que “minha máquina local é o cliente.”
  • As pessoas enfatizam que a terminologia do X combina com as normas de redes, uma vez explicada.

Captura de Entrada e Peculiaridades de Interação

  • XGrabPointer/XGrabKeyboard direcionam eventos para uma janela específica независимо da focalização do ponteiro, permitindo recursos como menus em cascata e comportamentos robustos de arrastar.
  • Mecanismos semelhantes existem em outros lugares (por exemplo, captura do mouse no Windows); sem eles, arrastos que cruzam limites de janela se comportariam mal.
  • O comportamento da roda de rolagem difere entre sistemas e épocas: alguns sempre rolam a janela sob o cursor, outros historicamente exigiam foco explícito; o Windows adicionou “rolar janelas inativas” relativamente tarde.

Incorporando Janelas e Composição

  • XEmbed aproveita o fato de que “tudo é uma janela” para que um app possa tornar a janela de outro app sua filha (por exemplo, contêineres com abas, navegadores incorporáveis, plugins de áudio).
  • O Win32 pode tecnicamente reparentear janelas de topo entre processos, mas sofre com problemas de desempenho e complexidade (trocas de thread/contexto, filas de entrada).
  • Alguns componentes modernos (por exemplo, web views fora do processo) desfocam essa fronteira por meio de plumbing mais complexo; como isso se mapeia para o Wayland é visto como incerto.

Skins, Temas e Consistência de UI

  • Controles nativos do Windows eram difíceis de aplicar skins, o que levou a UIs desenhadas sob medida e bibliotecas de skinning de terceiros, especialmente na era do XP.
  • Isso gerou muitas UIs “parecidas com XP, mas erradas”, que imitavam visualmente os temas do sistema sem fidelidade ao comportamento ou às métricas.
  • No Mac clássico, existiam UIs fortemente não nativas, mas frequentemente eram mal vistas pelos usuários, encaradas como exceções e não como regra.
  • Há tensão entre dar liberdade para os apps desenharem tudo e preservar uma aparência e um comportamento consistentes e acessíveis no desktop.

Toolkits Históricos e Nostalgia

  • O X é lembrado como elegante para a sua época, especialmente pela transparência de rede, mas toolkits iniciais (por exemplo, Motif) eram dolorosos de usar.
  • Toolkits mais novos como GTK e Tk pareciam mais acessíveis; outros lembram com carinho da API C do XView, cheia de varargs.
  • Vários observam que o estilo de “muitas janelas pequenas” hoje é um conhecimento relativamente obscuro entre desenvolvedores modernos, embora as ideias subjacentes continuem vivas em DOMs e hierarquias de views no estilo MVC.