1 pontos por GN⁺ 2025-08-16 | Ainda não há comentários. | Compartilhar no WhatsApp
  • A equipe do Ghostty reescreveu completamente o aplicativo GTK, passando a usar ativamente o sistema de tipos GObject
  • Nesse processo, a integração com a linguagem Zig e a verificação de problemas de memória com o Valgrind tiveram papel importante
  • Com a adoção do sistema GObject, a gestão de memória e a implementação de widgets personalizados ficaram mais simples do que antes
  • Ao usar o Valgrind, a equipe constatou uma grande melhora na segurança de memória do Ghostty
  • O novo Ghostty GTK se tornou o padrão para builds a partir do código-fonte e será incluído na versão 1.2

Introdução

  • Ghostty é um emulador de terminal multiplataforma com suporte a macOS, Linux e FreeBSD
  • Ele se diferencia por usar frameworks de GUI nativos em cada plataforma
    • macOS: aplicativo de grande porte baseado em Swift e Xcode
    • Linux e BSD: aplicativo baseado em GTK, com integração direta com X11/Wayland etc.
    • O núcleo comum é escrito em Zig e fornece uma API compatível com C ABI
  • O motivo para reescrever o aplicativo GTK na estrutura anterior pode ser consultado no PR original
  • Este texto foca principalmente na integração com o sistema de tipos GObject e nos problemas de memória verificados com Valgrind

Sistema de tipos GObject e Zig

  • Ao usar GTK, a estrutura naturalmente exige interface com o sistema de tipos GObject
  • No passado, a equipe tentou evitar o sistema GObject e alinhar manualmente o ciclo de vida entre objetos Zig sem contagem de referência e objetos GObject, mas isso repetidamente gerava problemas de liberação incorreta de memória
    • Ex.: a memória do lado do Zig já havia sido liberada, mas a memória do lado do GTK ainda estava viva, ou o contrário
  • Essa abordagem dificultava não só a correção, mas também o uso de recursos próprios do GTK como sinais de evento, associação de propriedades e ações
  • Um exemplo concreto era o recarregamento da struct de configuração (config): todos os elementos de GUI conectados precisavam ser atualizados de forma consistente, e esse processo era complexo e propenso a erros
    • Agora isso é gerenciado por meio de um GhosttyConfig GObject com contagem de referência que encapsula a struct Config em Zig, e as notificações de mudança de propriedade propagam naturalmente as alterações por todo o aplicativo
  • Também ficou mais fácil criar widgets GObject personalizados, permitindo o uso de tecnologias modernas de UI do GTK, como o Blueprint
    • Recentemente, com a adoção do Blueprint, ficou mais fácil adicionar novos recursos como abas na barra de título do GTK e borda animada do sino

Valgrind, GTK e Zig

  • Durante todo o processo de desenvolvimento, o Valgrind foi usado para verificar sistematicamente vazamentos de memória, acessos a memória indefinida e outros problemas
  • Inspecionar aplicativos GTK com Valgrind é trabalhoso e exige um grande conjunto de arquivos de suppression (80% para o próprio GTK, o restante para bibliotecas de terceiros e drivers de GPU)
  • As verificações repetidas permitiram encontrar antecipadamente bugs de memória complexos que só ocorriam em alguns casos
    • Ex.: se um WeakRef de GObject não for inicializado corretamente, pode ocorrer acesso a memória indefinida quando o objeto-alvo for liberado depois; o Valgrind permitiu detectar isso antes
  • Na experiência prática, houve apenas 2 problemas dentro do codebase Zig (1 vazamento e 1 acesso indefinido), e ambos surgiram durante a integração com APIs C de terceiros
    • O alocador de depuração do Zig e seus recursos de integração com o Valgrind também provaram sua eficácia
  • Os outros problemas de memória encontrados vieram, em sua maioria, da fronteira com APIs C e do complexo gerenciamento de ciclo de vida do sistema GObject
    • Em resumo, para usar com segurança a API C de bibliotecas complexas, são necessárias ferramentas como o Valgrind
  • Os recursos auxiliares de segurança de memória do Zig mostraram eficácia não apenas em discussões teóricas, mas também na experiência prática de um projeto real

Conclusão

  • Esta foi a quinta vez que a parte de GUI do Ghostty foi refeita do zero
    • Na ordem: GLFW, macOS SwiftUI, macOS AppKit+SwiftUI, Linux GTK (procedural), Linux GTK+sistema de tipos GObject
  • Em cada reescrita repetida, houve novas lições e crescimento técnico
    • Há planos de aplicar parte dessa experiência também ao projeto no macOS
  • Também foi destacada a colaboração ativa da equipe de manutenção do sistema Ghostty GTK
  • O aplicativo Ghostty GTK recém-reescrito agora se tornou o padrão para builds a partir do código-fonte e será aplicado no lançamento oficial 1.2

Ainda não há comentários.

Ainda não há comentários.