Term.everything - Ejecutar cualquier app GUI desde la terminal

• Programa CLI para Linux que permite ejecutar aplicaciones GUI directamente desde la terminal
• Usa un compositor Wayland propio para enviar la salida gráfica a la terminal en lugar de a un monitor
• También puede ejecutarse en entornos con ssh, y permite usar navegadores web, gestores de archivos e incluso el juego Doom dentro de la terminal
• La calidad de salida varía según la resolución de la terminal (número de filas y columnas), y en terminales con soporte de imágenes como iTerm2 y kitty también admite renderizado a resolución completa
• Está desarrollado con Typescript y bun, e incluye algo de código en C++; por ahora solo soporta algunas apps, pero sigue ampliándose con el objetivo de “Term everything❗”

---

Importancia del proyecto y ventajas comparativas

• A diferencia de los visores de archivos para terminal tradicionales o de herramientas simples de salida de imágenes, Term.everything puede ejecutar “todas” las aplicaciones GUI dentro de la terminal
• Puede usar interfaces GUI incluso en entornos de red, incluido SSH, lo que le da ventajas para administración de servidores y desarrollo remoto
• Aprovecha al máximo las capacidades de imagen de terminales modernas como kitty e iterm2, y ofrece opciones para mejorar resolución y tasa de fotogramas

Resumen general

• Term.everything es un programa CLI para Linux, y su rasgo principal es permitir ejecutar ventanas GUI directamente en la terminal
• Su pieza clave es un compositor basado en Wayland desarrollado por el proyecto, que renderiza la GUI en la terminal en vez de en un monitor normal
• Soporta tanto x11 como entornos basados en Wayland, y también puede usarse de forma remota mediante ssh
• La cantidad limitada de filas y columnas de la terminal afecta la calidad de la ventana; aumentar la resolución de la terminal puede mejorarla, aunque con posible impacto en el rendimiento

Principales casos de uso

• Ejecución de juegos: permite correr juegos como Fontemon o Doom (episodio shareware) dentro de la terminal
• Reproducción de video: reproduce la película Wing It!, con posibilidad de ajustar la resolución para equilibrar tasa de fotogramas y calidad de imagen
• Navegación web: permite conectarse a Ubuntu con iTerm2 + ssh y ejecutar Firefox
• Alternativa a visores de archivos: en vez de crear un visor de archivos específico para terminal, se puede usar directamente un gestor de archivos GUI existente desde la terminal
• Ejecución recursiva: ejecutar otra terminal dentro de la terminal, es decir, un "terminal in a terminal"

Funcionamiento e información de desarrollo

• Concepto básico

  • En el pasado, para dibujar algo en pantalla, los programas podían escribir directamente en una región específica de la RAM
  • En los sistemas modernos, el servidor de pantalla (Display Server) gestiona la entrada y salida, coordinando entradas como mouse y teclado, y salidas como gráficos e imágenes
  • En Linux se usa principalmente el protocolo Wayland o X11, y Term.everything funciona sobre Wayland

• Protocolo Wayland

  • Wayland no es el servidor de pantalla en sí, sino un protocolo que define la comunicación entre el servidor y los programas
  • Los programas entregan al servidor de pantalla el resultado que renderizan directamente, y el servidor lo muestra en pantalla
  • Un punto importante es que no impone un modelo de renderizado → el programa puede dibujar de la forma que quiera
  • Gracias a eso, la salida puede enviarse a otro lugar en vez de a la pantalla (por ejemplo, la terminal)

• Procesamiento de salida en Term.everything

  • Recibe la imagen dibujada por el cliente Wayland (la app GUI ejecutada) y la convierte en salida de caracteres para terminal
  • Proceso de conversión:
    • 1. Recibir los datos de imagen enviados por el cliente
    • 2. Convertirlos en caracteres UTF-8 + códigos de escape ANSI
    • 3. Para la conversión se usa la biblioteca chafa para mapear píxeles a caracteres de terminal
  • La entrada se transmite al cliente Wayland mediante eventos de teclado y mouse enviados a través de stdin

• Implementación real

  • La idea central es sencilla, pero la implementación real requiere alrededor de diez mil líneas de código
  • Está escrito en Typescript (basado en bun) y algo de C++, y cumple el rol de servidor de pantalla Wayland personalizado
  • El código fuente puede revisarse en el directorio src/

• Posibilidades de expansión

  • Term.everything apunta a algo más que simplemente ejecutar una GUI en la terminal
  • Con un servidor de pantalla personalizado basado en Wayland, también podría hacer posibles otras ideas experimentales
  • Por ejemplo: conectar el dispositivo de salida no a una terminal, sino a otro medio completamente distinto (por ejemplo, una impresora, una obra de arte física, etc.)

[iolothebard]

Una capa sobre otra

[ifmkl]

Esto sí es realmente geek jaja

[hybridego]

¿Por qué a mí solo me aparece el logo y no funciona??

[bus710]

Yo usaba Synergy para controlar mi Mac personal desde la Mac de la empresa. Ahora vendí mi Mac personal y solo uso Linux, así que mi flujo de trabajo se volvió más engorroso.

Entonces, ¿con esta herramienta podría conectarme desde la terminal de la Mac de la empresa a mi escritorio Linux personal y hacer todo tipo de tareas libremente?

Me imagino que al equipo de seguridad no le va a gustar mucho.

[coremaker]

Yo también soy un viejo lobo de mar en esto, supongo, pero ¿de verdad hace falta esto?

[cgl00]

Parece que será útil para hacer experimentos web en el servidor (vía localhost).

[coremaker]

Se refiere a cuando quieres resolverlo en local y probarlo antes de desplegarlo, ¿verdad?
Trabajar de forma remota, cuando era un entorno limitado por la dificultad de acceder a la red interna...

[t7vonn]

Si abres iTerm dentro de iTerm con term.everything... ¿funciona?

[GN⁺]

Comentarios en Hacker News

• Me parece un proyecto totalmente inútil pero genial, está en la frontera entre la programación y el arte, creo que debió haber sido una experiencia de aprendizaje muy divertida, de verdad quiero decir que está muy bien hecho
  • No creo que sea 100% inútil, podría ser útil para apps que corren dentro de contenedores Docker, normalmente hay formas de levantar apps GUI dentro de contenedores, pero esto quizá sea más fácil, aunque ejecutar apps GUI en Docker es más fácil de lo que parece, voy a probar mañana siguiendo esta guía, y me da curiosidad si también funciona en Windows
  • Me cuesta explicar por qué este proyecto me hace tan feliz, pero aunque probablemente no tenga muchos usos reales, nada más pensarlo se me dibuja una sonrisa tonta en la cara
• Este es el tipo de proyecto que hace que uno ya no sepa dónde están los límites, es realmente genial y es un resultado del que presumiría sin parar, me parece impresionante y me hace pensar en cómo deberíamos implementar VDI en el equipo de aquí en adelante, se siente como si le diera un nuevo significado a la frase ghost in the shell, y por cierto, me pregunto si también podrá correr doom
  • Si te da curiosidad, puedes ver doom corriendo, hice que funcionara con unas cuantas modificaciones porque term.everything solo recibe entrada por stdin, y tiene buena compatibilidad con varios terminales a través de ssh
    1. Mapeé la tecla Control a otra tecla (originalmente se usa para enviar señales)
    2. Tuve que ajustar el timeout de entrada. La entrada basada en stdin solo recibe eventos keydown y no genera eventos keyup, así que hay que adivinar en qué momento el usuario soltó la tecla; normalmente se puede enviar keyup de inmediato, pero en doom, por el manejo de rebote de teclas, tuve que esperar unos 50~100 ms, en un juego normalmente basta con mantener presionada la flecha hacia arriba para avanzar, pero con este método hay que pulsarla repetidamente, así que es un poco incómodo, pero sí corre y se puede jugar
  • aaquake es un juego que ya se había ejecutado en un entorno de terminal ASCII incluso antes de proyectos como este
• Me parece un proyecto realmente genial, personalmente creo que habrá muchos más casos de uso interesantes basados en Wayland, también me interesa algo como el proyecto greenfield
• Cuando vi hace tiempo el proyecto carbonyl corriendo chromium en la terminal me emocioné muchísimo (ver aquí), pero ahora ya no tiene mantenimiento, este proyecto se siente como una evolución de esa idea, sinceramente me parece un resultado increíble
• Creo que bash_completion debería ser muchísimo más fácil de usar, en la práctica es más difícil de escribir de lo que parece, incluso copiar y pegar resulta engorroso, los desarrolladores listos crean apps que encajan bien con bash_completion desde el principio, por ejemplo, si el primer argumento clave es amigable con bash, con una estructura como mycli myfunc ... puedes descubrir todas las funciones de inmediato con una sola tecla Tab, ni siquiera hace falta anunciar funciones nuevas, si solo las quitas del completion no rompes scripts existentes y puedes deprecar funcionalidades de forma natural, al final todo termina estando en el CLI porque alguien ya hizo ese trabajo antes
• Para alguien como yo, que a veces necesita acceder directamente a un escritorio o a un navegador en una máquina de compilación, VNC u otros métodos para compartir escritorio no son prácticos o tienen problemas de seguridad, creo que este proyecto sería de gran ayuda en esas situaciones
• Me parece un proyecto realmente útil, podría servir para tareas remotas puntuales, no sé bien cómo funciona la parte de conectarse remotamente a un programa en ejecución, desconectarse luego, o hacer mirroring de pantalla, pero si pudiera entrar por SSH a un escritorio y manipular un cliente ya abierto como Discord, sería muy conveniente, por cierto, también me gustaría revisar funciones de RDP relacionadas con ejecución remota de apps
  • También podrías simplemente usar un cliente de Discord para CLI, o correr un cliente IRC conectado a un servidor Bitlbee
• Tendré que anotarme la parte de <i>en la terminal</i>, para recordarme a mí mismo que esto probablemente no funcionaría en modo texto
  • Pero, ¿el primer ejemplo (el ejemplo del cómic) no era modo texto?
• Espero que el proyecto siga evolucionando, ojalá nunca se detenga
• ¡De verdad me parece impresionante! Seguro cada quien tendrá sus propios casos de uso, pero para mí me entusiasma la idea de usar VSCode en un iPad, ojalá algún día también pueda soportar iPadOS
  • Yo normalmente uso code-server para desarrollo remoto y con eso me basta
  • Como hay clientes ssh para iPad, creo que sí se puede, pienso intentarlo ahora mismo