Term.everything - Exécuter toutes les applications GUI dans le terminal

• Programme CLI pour Linux qui permet d’exécuter directement des applications GUI dans le terminal
• Utilise un compositeur Wayland maison pour envoyer la sortie GUI vers le terminal au lieu d’un moniteur
• Fonctionne aussi via ssh, et permet d’exécuter dans le terminal un navigateur web, un gestionnaire de fichiers, et même le jeu Doom
• La qualité d’affichage varie selon la résolution du terminal (nombre de lignes et de colonnes), et les terminaux prenant en charge les images comme iTerm2 ou kitty permettent aussi un rendu en pleine résolution
• Développé en Typescript sur bun avec une partie du code en C++, le projet ne prend encore en charge qu’une partie des applications mais s’étend avec l’objectif « Term everything❗ »

---

Importance du projet et avantages comparatifs

• Contrairement aux visionneuses de fichiers en terminal existantes ou aux simples outils d’affichage d’images, Term.everything permet d’exécuter « toutes » les applications GUI dans le terminal
• Il permet d’utiliser une interface GUI même dans des environnements réseau, y compris en SSH, ce qui constitue un atout pour l’administration serveur et le développement à distance
• Exploite au maximum les capacités d’image des terminaux modernes comme kitty et iterm2, avec des options pour améliorer la résolution et le framerate

Vue d’ensemble

• Term.everything est un programme en CLI Linux, dont la particularité est de permettre l’exécution directe de fenêtres GUI dans le terminal
• Son cœur est un compositeur basé sur Wayland développé sur mesure, qui effectue le rendu de l’interface GUI vers le terminal au lieu d’un écran classique
• Il prend en charge à la fois x11 et Wayland, et peut aussi être utilisé à distance via ssh
• Le nombre limité de lignes et de colonnes du terminal influe sur la qualité de la fenêtre, et augmenter la résolution du terminal permet d’améliorer le rendu (au prix possible d’une baisse de performances)

Principaux cas d’usage

• Exécution de jeux : permet de lancer dans le terminal des jeux comme Fontemon ou Doom (épisode shareware)
• Lecture vidéo : lecture du film Wing It!, avec possibilité d’ajuster la résolution pour équilibrer framerate et qualité d’image
• Lancement de navigateur : dans un environnement iTerm2 + ssh, il est possible de se connecter à Ubuntu et d’y lancer Firefox
• Alternative aux visionneuses de fichiers : au lieu de créer un gestionnaire de fichiers spécifique au terminal, on peut utiliser directement un gestionnaire de fichiers GUI existant dans le terminal
• Exécution récursive : lancer un autre terminal à l’intérieur du terminal, un « terminal in a terminal »

Fonctionnement et informations de développement

• Concept de base

  • Par le passé, lorsqu’un programme devait afficher quelque chose à l’écran, il pouvait écrire directement dans une zone spécifique de la RAM
  • Sur les systèmes modernes, c’est le serveur d’affichage (Display Server) qui gère les entrées/sorties et coordonne les entrées comme la souris et le clavier avec la sortie graphique et les images
  • Sous Linux, on utilise principalement le protocole Wayland ou X11, et Term.everything fonctionne sur la base de Wayland

• Protocole Wayland

  • Wayland n’est pas le serveur d’affichage lui-même, mais un protocole qui définit la communication entre le serveur et les programmes
  • Les programmes transmettent au serveur d’affichage le résultat de leur rendu, et le serveur l’affiche à l’écran
  • Point important : aucun modèle de rendu n’est imposé → les programmes peuvent dessiner de la manière qu’ils souhaitent
  • Il est ainsi possible d’envoyer le résultat de sortie ailleurs que vers un écran (par exemple vers un terminal)

• Traitement de la sortie dans Term.everything

  • Reçoit les images dessinées par les clients Wayland (applications GUI exécutées) et les convertit en sortie texte pour terminal
  • Processus de conversion :
    • 1. réception des données d’image envoyées par le client
    • 2. conversion en caractères UTF-8 + codes d’échappement ANSI
    • 3. utilisation de la bibliothèque chafa pour mapper les pixels vers des caractères de terminal
  • Les entrées sont transmises aux clients Wayland sous forme d’événements clavier et souris reçus via stdin

• Implémentation réelle

  • L’idée de base est simple, mais l’implémentation réelle nécessite environ dix mille lignes de code
  • Écrit en Typescript (sur bun) avec une partie en C++, il joue le rôle d’un serveur d’affichage Wayland personnalisé
  • Le code source peut être consulté dans le répertoire src/

• Potentiel d’extension

  • Term.everything ne vise pas seulement à exécuter des GUI dans le terminal
  • En s’appuyant sur un serveur d’affichage personnalisé basé sur Wayland, il pourrait aussi permettre de mettre en œuvre d’autres idées expérimentales
  • Exemple : connecter le périphérique de sortie non pas au terminal, mais à un support totalement différent (par exemple une imprimante, une œuvre d’art physique, etc.)

[iolothebard]

Une surcouche inutile.

[ifmkl]

C’est ça, le vrai esprit geek 😄

[hybridego]

Pourquoi, chez moi, seul le logo s’affiche et rien ne se passe ??

[bus710]

J’utilisais Synergy pour contrôler mon Mac personnel depuis le Mac de l’entreprise. Maintenant, comme je me suis séparé de mon Mac perso et que je n’utilise plus que Linux, mon workflow est devenu plus contraignant.

Mais si j’utilise cet outil, ça veut dire que je peux me connecter depuis le terminal du Mac de l’entreprise à mon desktop Linux personnel et y faire toutes sortes de tâches librement ?

J’ai comme l’impression que l’équipe sécurité ne va pas apprécier.

[coremaker]

Je suis peut-être juste un vieux briscard, mais est-ce que c'est vraiment nécessaire ?

[cgl00]

Cela semble utile pour mener des expérimentations liées au web sur un serveur (via localhost).

[coremaker]

Vous parlez de vouloir résoudre cela en local et le tester avant le déploiement, c’est bien ça ?
Quand il fallait travailler à distance ou qu’il s’agissait d’un environnement limité avec un accès difficile au réseau interne...

[t7vonn]

Si on ouvre iTerm dans iTerm avec term.everything... ça marche ?

[GN⁺]

Commentaires sur Hacker News

• Je pense que c’est un projet à la fois complètement inutile et génial, à la frontière entre programmation et art ; je suis sûr que ça a été une expérience d’apprentissage très amusante, et j’ai vraiment envie de dire bravo
  • Ce n’est sans doute pas inutile à 100 %, ça pourrait être pratique pour des apps exécutées dans un conteneur Docker ; il existe en général des moyens de lancer des apps GUI dans un conteneur, mais ça pourrait être plus simple comme ça ; cela dit, exécuter des apps GUI dans Docker est plus facile qu’on ne le pense ; je vais tester demain en suivant ce guide, et je me demande si ça marche aussi sous Windows
  • J’ai du mal à expliquer pourquoi ce projet me rend aussi heureux, mais même si je ne pense pas m’en servir souvent, rien que d’y penser me donne un sourire idiot
• C’est le genre de projet qui fait perdre toute notion de limite ; c’est vraiment magnifique et le genre de résultat qu’on a envie de montrer fièrement sans fin ; je trouve ça impressionnant, et ça me fait réfléchir à la manière dont notre équipe devrait implémenter le VDI à l’avenir ; ça donne un nouveau sens à l’expression ghost in the shell ; au fait, je me demande si on peut aussi faire tourner doom
  • Si vous êtes curieux, vous pouvez voir doom en action, j’ai fait en sorte que ça fonctionne en modifiant quelques lignes parce que term.everything n’accepte les entrées que via stdin, et la compatibilité est bonne avec différents terminaux via ssh
    1. J’ai remappé la touche Control vers une autre touche (à l’origine elle sert à envoyer des signaux)
    2. Il a fallu ajuster le délai d’expiration des entrées. Les entrées via stdin ne reçoivent que des événements keydown, sans événement keyup ; il faut donc deviner à quel moment l’utilisateur a relâché la touche, et en général on peut envoyer keyup immédiatement, mais dans doom, à cause du debounce des touches, il a fallu attendre environ 50 à 100 ms ; dans le jeu, pour avancer, on garde normalement la flèche du haut enfoncée, mais avec la méthode actuelle il faut appuyer de façon répétée, ce qui est un peu inconfortable, même si ça fonctionne et qu’on peut jouer
  • aaquake est un jeu qui tournait déjà dans un terminal ASCII avant ce type de projet
• Je trouve ce projet vraiment génial ; personnellement, je pense qu’on verra davantage de cas d’usage intéressants de ce genre avec Wayland, et je m’intéresse aussi à des projets comme greenfield
• J’avais été vraiment emballé à l’époque en voyant le projet carbonyl faire tourner chromium dans le terminal (voir ici), mais il n’est plus maintenu aujourd’hui ; ce projet donne l’impression d’être une version encore plus poussée de cette idée, et je le trouve sincèrement impressionnant
• Je pense qu’il faut rendre bash_completion vraiment simple à utiliser ; en pratique, c’est plus difficile à écrire qu’on ne le croit, même un simple copier-coller est pénible ; les développeurs malins conçoivent dès le départ des apps qui se marient bien avec bash_completion ; par exemple, si le premier argument clé est compatible avec bash, une structure du type mycli myfunc ... suffit pour découvrir toutes les fonctionnalités d’un simple appui sur Tab ; pas besoin de promouvoir les nouvelles fonctionnalités ; il suffit de les retirer du completion pour les déprécier naturellement sans casser les scripts existants ; au final, tout finit dans le CLI parce que quelqu’un a déjà fait ce travail
• Quand, comme moi, on doit parfois intervenir directement sur le bureau ou dans un navigateur depuis une machine de build, les solutions comme VNC ou les autres formes de partage de bureau ne sont pas pratiques ou posent des problèmes de sécurité ; je pense que ce projet pourrait beaucoup aider dans ce genre de situation
• Je pense que c’est un projet vraiment utile ; pour des interventions ponctuelles à distance, ça a l’air intéressant ; je ne sais pas trop ce qu’il en est pour se rattacher à un programme déjà lancé, s’en détacher ensuite, ou pour la partie mirroring d’écran ; mais si on pouvait se connecter en SSH à un bureau et manipuler un client déjà ouvert comme Discord, ce serait pratique ; au passage, j’aimerais aussi regarder les fonctionnalités RDP liées à l’exécution d’apps à distance
  • On peut aussi simplement utiliser un client Discord en CLI, ou lancer un client IRC connecté à un serveur Bitlbee
• Il faut bien noter le <i>dans le terminal</i> ; je me rappelle à moi-même que ça ne semble pas fonctionner en mode texte
  • Cela dit, le premier exemple (l’exemple de la BD) n’était-il pas justement en mode texte ?
• J’espère que le projet continuera d’évoluer, j’aimerais vraiment qu’il ne s’arrête jamais
• Je trouve ça vraiment impressionnant ! Chacun aura sans doute ses propres cas d’usage, mais pour moi, j’attends surtout de pouvoir faire tourner VSCode sur iPad ; j’espère qu’un support d’iPadOS sera possible un jour
  • Pour le développement à distance, j’utilise généralement code-server, et je trouve déjà que ça suffit largement
  • Il existe des clients ssh pour iPad, donc je pense que c’est possible ; je vais essayer tout de suite