Term.everything - Executando qualquer app GUI no terminal

• Um programa CLI para Linux que permite executar aplicativos GUI diretamente no terminal
• Usa um compositor Wayland próprio para enviar a saída gráfica ao terminal em vez de a um monitor
• Também pode ser executado em ambientes ssh, permitindo rodar navegador web, gerenciador de arquivos e até o jogo Doom dentro do terminal
• A qualidade da saída varia conforme a resolução do terminal (número de linhas e colunas), e em terminais com suporte a imagem, como iTerm2 e kitty, há suporte a renderização em resolução total
• Foi desenvolvido com Typescript e bun, inclui algum código em C++, e atualmente suporta apenas parte dos apps, mas está sendo expandido com o objetivo de "Term everything❗"

---

Importância do projeto e vantagens comparativas

• O Term.everything, diferentemente de visualizadores de arquivos para terminal ou ferramentas simples de saída de imagem, consegue executar “todos” os aplicativos GUI dentro do terminal
• Como permite usar interfaces gráficas mesmo em ambientes de rede, incluindo SSH, tem pontos fortes em administração de servidores e desenvolvimento remoto
• Aproveita ao máximo os recursos de imagem de terminais modernos como kitty e iTerm2, oferecendo opções para melhorar resolução e taxa de quadros

Visão geral

• O Term.everything é um programa CLI para Linux, cuja principal característica é permitir executar janelas GUI diretamente no terminal
• Seu núcleo é um compositor baseado em Wayland desenvolvido sob medida, que renderiza a GUI no terminal em vez de em um monitor convencional
• Suporta ambientes baseados em X11 e Wayland, e também pode ser usado remotamente via ssh
• As linhas e colunas limitadas do terminal afetam a qualidade da janela, e aumentar a resolução do terminal pode melhorar a qualidade (embora possa haver perda de desempenho)

Principais exemplos de uso

• Execução de jogos: é possível rodar jogos como Fontemon e Doom (episódio shareware) dentro do terminal
• Reprodução de vídeo: reprodução do filme Wing It!, com possibilidade de ajustar a resolução para equilibrar taxa de quadros e qualidade de imagem
• Execução de navegador: é possível acessar um Ubuntu via iTerm2 + ssh e executar o Firefox
• Substituto de visualizador de arquivos: em vez de criar um visualizador de arquivos específico para terminal, é possível usar diretamente um gerenciador de arquivos GUI existente no terminal
• Execução recursiva: rodar outro terminal dentro do terminal, o famoso "terminal dentro de um terminal"

Como funciona e informações de desenvolvimento

• Conceito básico

  • No passado, para um programa desenhar algo na tela, ele podia gravar diretamente em uma área específica da RAM
  • Nos sistemas modernos, o servidor de exibição (Display Server) gerencia entrada e saída, coordenando entradas como mouse/teclado e saídas gráficas/de imagem
  • Em ambientes Linux, normalmente são usados o protocolo Wayland ou o X11, e o Term.everything funciona com base no Wayland

• Protocolo Wayland

  • Wayland não é o próprio servidor de exibição, mas um protocolo que define a comunicação entre o servidor e os programas
  • Os programas enviam ao servidor de exibição o resultado que renderizaram diretamente, e o servidor o mostra na tela
  • O ponto importante é que o modelo de renderização não é imposto → o programa pode desenhar da forma que quiser
  • Graças a isso, é possível enviar a saída para outro lugar em vez da tela (por exemplo, o terminal)

• Processamento de saída no Term.everything

  • Recebe a imagem desenhada pelo cliente Wayland (o app GUI em execução) e a converte em saída de caracteres no terminal
  • Processo de conversão:
    • 1. Receber os dados de imagem enviados pelo cliente
    • 2. Convertê-los em caracteres UTF-8 + códigos de escape ANSI
    • 3. Na conversão, usar a biblioteca chafa para mapear pixels em caracteres de terminal
  • A entrada é repassada ao cliente Wayland como eventos de teclado e mouse enviados via stdin

• Implementação real

  • A ideia central é simples, mas a implementação real exigiu cerca de dez mil linhas de código
  • Foi escrito em Typescript (baseado em bun) com um pouco de C++, desempenhando o papel de servidor de exibição Wayland customizado
  • O código-fonte pode ser visto no diretório src/

• Potencial de expansão

  • O Term.everything pretende ir além de simplesmente executar GUI no terminal
  • Com um servidor de exibição customizado baseado em Wayland, também pode viabilizar outras ideias experimentais
  • Exemplo: conectar o dispositivo de saída não ao terminal, mas a um meio totalmente diferente (como impressoras, obras de arte físicas etc.)

[iolothebard]

Uma redundância desnecessária

[ifmkl]

Isso sim é geek de verdade haha

[hybridego]

Por que para mim só aparece o logo e não funciona??

[bus710]

Eu uso o Mac da empresa para controlar meu Mac pessoal e usava o Synergy. Agora vendi meu Mac pessoal e passei a usar só Linux, então meu fluxo de trabalho ficou mais complicado.

Mas então, com essa ferramenta eu poderia acessar meu desktop Linux pessoal pelo terminal do Mac da empresa e fazer à vontade todo tipo de coisa por lá, certo?

De qualquer forma, acho que a equipe de segurança não vai gostar disso.

[coremaker]

Talvez eu seja um veterano nisso, mas isso é realmente necessário?

[cgl00]

Parece que será útil para fazer experimentos relacionados à web em um servidor (via localhost).

[coremaker]

Você quer dizer quando deseja resolver localmente e testar antes de fazer o deploy, certo?
Trabalhar remotamente, quando era um ambiente restrito por ser difícil acessar a rede interna...

[t7vonn]

Se você abrir o iTerm dentro do iTerm com o term.everything... funciona?

[GN⁺]

Comentários do Hacker News

• Acho que é um projeto completamente inútil e, ao mesmo tempo, incrível; fica na fronteira entre programação e arte. Acredito que deve ter sido uma experiência de aprendizado muito divertida, e quero dizer que ficou realmente muito bem feito.
  • Não parece ser 100% inútil. Acho que pode ser útil para apps rodando dentro de containers Docker. Normalmente já existem formas de abrir apps GUI dentro de containers, mas isso talvez seja mais simples. Dito isso, executar apps GUI no Docker é mais fácil do que parece. Pretendo testar amanhã usando este guia, e fiquei curioso para saber se funciona também no Windows.
  • É difícil explicar por que esse projeto me deixa tão feliz, mas, embora eu ache que eu dificilmente vá usá-lo na prática, só de pensar nele já me vem um sorriso bobo no rosto.
• Este é o tipo de projeto que faz você perder a noção de onde estão os limites. É algo realmente incrível e que dá vontade de sair mostrando para todo mundo sem parar. Fiquei impressionado e me fez pensar em como nossa equipe deveria implementar VDI daqui para frente. Dá até um novo sentido à expressão ghost in the shell. Aliás, será que roda doom?
  • Se estiver curioso, dá para ver doom rodando. O term.everything só recebe entrada via stdin, então fiz algumas alterações em poucas linhas para fazê-lo funcionar. A compatibilidade com vários terminais via ssh é alta.
    1. Remapeei a tecla Control para outra tecla (a original é usada para enviar sinais).
    2. Precisei ajustar o timeout de entrada. Entrada baseada em stdin só recebe eventos de keydown, não de keyup, então é preciso adivinhar em que momento o usuário soltou a tecla. Normalmente dá para enviar keyup imediatamente, mas no doom, por causa do tratamento de debounce das teclas, foi preciso esperar algo em torno de 50~100ms. Em jogos, normalmente basta manter a seta para cima pressionada para andar para frente, mas do jeito atual é preciso apertá-la repetidamente, então fica um pouco incômodo — ainda assim, roda e dá para jogar.
  • aaquake já era um jogo que rodava em ambiente de terminal ASCII antes mesmo de projetos como este.
• Acho este projeto realmente incrível. Pessoalmente, acho que vamos ver mais casos de uso interessantes baseados em Wayland, e também tenho interesse em projetos como o greenfield.
• Fiquei muito empolgado quando vi o projeto carbonyl rodando o chromium no terminal antigamente (veja aqui), mas hoje ele não é mais mantido. Este projeto parece uma evolução daquela ideia, e sinceramente acho o resultado muito impressionante.
• Acho que bash_completion deveria ser algo muito fácil de usar. Na prática, é mais difícil de escrever do que parece, e até um simples copiar e colar já é incômodo. Desenvolvedores inteligentes criam apps que combinam bem com bash_completion desde o começo. Por exemplo, se o primeiro argumento principal for amigável ao bash, uma estrutura como mycli myfunc ... já permite descobrir todas as funções com um único Tab. Nem é preciso anunciar novos recursos. Se você simplesmente removê-los do completion, scripts antigos não quebram e ainda dá para descontinuar funcionalidades de forma natural. No fim, tudo acaba indo parar na CLI porque alguém já preparou isso antes.
• Para quem, como eu, às vezes precisa acessar diretamente o desktop ou o navegador em uma máquina de build para fazer alguma tarefa, VNC ou outros métodos de compartilhamento de desktop não são práticos ou trazem problemas de segurança. Acho que este projeto pode ajudar bastante nessas situações.
• Acho que é um projeto realmente útil. Parece bom para tarefas remotas pontuais. Não sei bem como funcionam a parte de se conectar remotamente a um programa já em execução, depois se desconectar, ou o espelhamento de tela. Se fosse possível acessar um desktop por SSH e controlar um cliente já aberto, como o Discord, isso seria bem conveniente. Aliás, também gostaria de olhar os recursos de RDP para executar apps remotamente.
  • Talvez valha mais a pena usar um cliente de Discord para CLI, ou rodar um cliente IRC conectado a um servidor Bitlbee.
• Preciso anotar o detalhe de que isso é <i>no terminal</i>; estou me lembrando de que isso provavelmente não funcionaria em modo texto.
  • Mas o primeiro exemplo (o da tirinha) não era em modo texto?
• Espero que o projeto continue evoluindo; realmente gostaria que ele nunca parasse.
• Acho realmente impressionante! Cada pessoa provavelmente vai ter um caso de uso único, mas, para mim, o mais promissor seria rodar VSCode no iPad. Espero que um dia haja suporte a iPadOS.
  • Eu normalmente uso code-server para desenvolvimento remoto e acho que isso já é suficiente.
  • Como existem clientes ssh para iPad, acho que deve dar para fazer. Estou pensando em testar isso agora mesmo.