Term.everything – Alle GUI-Apps im Terminal ausführen

• Ein CLI-Programm für Linux, mit dem sich GUI-Anwendungen direkt im Terminal ausführen lassen
• Verwendet einen selbst entwickelten Wayland-Compositor, der die GUI-Ausgabe statt an einen Monitor an das Terminal weiterleitet
• Funktioniert auch in SSH-Umgebungen; Webbrowser, Dateimanager und sogar das Spiel Doom lassen sich im Terminal ausführen
• Die Ausgabequalität hängt von der Terminalauflösung (Anzahl der Zeilen und Spalten) ab; in bildunterstützenden Terminals wie iTerm2 und kitty wird auch Rendering in voller Auflösung unterstützt
• Entwickelt auf Basis von Typescript und bun, mit etwas C++-Code; derzeit werden nur einige Apps unterstützt, aber das Projekt wird mit dem Ziel „Term everything❗“ weiter ausgebaut

---

Bedeutung des Projekts und Vergleichsvorteile

• Im Unterschied zu bestehenden Terminal-Dateibetrachtern oder einfachen Bildausgabetools kann Term.everything „alle“ GUI-Anwendungen im Terminal ausführen
• Da sich die GUI auch in Netzwerkumgebungen einschließlich SSH nutzen lässt, ist es besonders stark bei Serververwaltung und Remote-Entwicklung
• Nutzt die Bildfunktionen moderner Terminals wie kitty und iTerm2 maximal aus und bietet Optionen zur Verbesserung von Auflösung und Framerate

Überblick

• Term.everything ist ein Linux-CLI-Programm, dessen Besonderheit darin besteht, GUI-Fenster direkt im Terminal auszuführen
• Das Herzstück ist ein selbst entwickelter Wayland-basierter Compositor, der die GUI nicht auf einem normalen Monitor, sondern im Terminal rendert
• Unterstützt sowohl x11- als auch Wayland-basierte Anwendungen und kann auch remote über SSH verwendet werden
• Die begrenzte Zahl an Terminalzeilen und -spalten beeinflusst die Fensterqualität; mit höherer Terminalauflösung lässt sich die Qualität verbessern, allerdings möglicherweise auf Kosten der Performance

Wichtige Einsatzbeispiele

• Spiele ausführen: Im Terminal lassen sich Spiele wie Fontemon oder Doom (Shareware-Episode) starten
• Video abspielen: Der Film Wing It! kann wiedergegeben werden; über die Auflösung lässt sich ein Gleichgewicht zwischen Framerate und Bildqualität einstellen
• Browser starten: In einer iTerm2- + SSH-Umgebung kann man sich mit Ubuntu verbinden und Firefox starten
• Alternative zu Dateibetrachtern: Statt eigens einen terminalspezifischen Dateibetrachter zu bauen, kann man bestehende GUI-Dateimanager direkt im Terminal verwenden
• Rekursive Ausführung: Ein weiteres Terminal innerhalb des Terminals ausführen, also ein "terminal in a terminal"

Funktionsweise und Entwicklungsinformationen

• Grundkonzept

  • Früher konnten Programme, wenn sie etwas auf dem Bildschirm darstellen wollten, direkt in einen bestimmten Bereich des RAM schreiben
  • In modernen Systemen verwaltet ein Display Server die Ein- und Ausgabe und koordiniert Eingaben wie Maus und Tastatur sowie Grafik- und Bildausgabe
  • Unter Linux werden hauptsächlich das Wayland-Protokoll oder X11 verwendet; Term.everything basiert auf Wayland

• Das Wayland-Protokoll

  • Wayland ist nicht der Display Server selbst, sondern ein Protokoll, das die Kommunikation zwischen Server und Programmen definiert
  • Programme übergeben ihre selbst gerenderten Ergebnisse an den Display Server, der sie auf dem Bildschirm ausgibt
  • Wichtig ist, dass kein bestimmtes Rendering-Modell erzwungen wird → Programme können auf die von ihnen gewünschte Weise zeichnen
  • Dadurch kann das Ausgabeergebnis statt auf den Bildschirm auch an einen anderen Ort gesendet werden, z. B. an ein Terminal

• Ausgabeverarbeitung in Term.everything

  • Nimmt die von Wayland-Clients (den gestarteten GUI-Apps) gezeichneten Bilder entgegen und wandelt sie in Terminal-Zeichenausgabe um
  • Umwandlungsprozess:
    • 1. Empfang der vom Client übermittelten Bilddaten
    • 2. Umwandlung in UTF-8-Zeichen + ANSI-Escape-Codes
    • 3. Für die Umwandlung wird die chafa-Bibliothek verwendet, die Pixel auf Terminalzeichen abbildet
  • Eingaben werden über stdin übergebene Tastatur- und Mausereignisse an die Wayland-Clients weitergereicht

• Tatsächliche Implementierung

  • Die Kernidee ist einfach, aber für die tatsächliche Implementierung sind etwa zehntausend Zeilen Code nötig
  • Geschrieben in Typescript (auf bun-Basis) und teilweise in C++; es übernimmt die Rolle eines benutzerdefinierten Wayland-Display-Servers
  • Der Quellcode ist im Verzeichnis src/ einsehbar

• Erweiterbarkeit

  • Term.everything will mehr sein, als nur GUI im Terminal auszuführen
  • Mit einem benutzerdefinierten, Wayland-basierten Display Server lassen sich möglicherweise auch andere experimentelle Ideen umsetzen
  • Zum Beispiel könnte das Ausgabegerät statt eines Terminals an ein völlig anderes Medium angebunden werden, etwa einen Drucker oder physische Kunstwerke

[iolothebard]

Doppelt gemoppelt

[ifmkl]

So etwas ist wirklich richtig geekig, haha.

[hybridego]

Warum wird bei mir nur das Logo angezeigt und sonst funktioniert nichts??

[bus710]

Ich habe meinen privaten Mac über den Firmen-Mac gesteuert und dafür Synergy verwendet. Da ich meinen privaten Mac inzwischen abgegeben habe und nur noch Linux nutze, ist mein Workflow umständlicher geworden.

Heißt das, dass ich mit diesem Tool vom Terminal des Firmen-Macs auf meinen privaten Linux-Desktop zugreifen und dort nach Belieben dies und das erledigen kann?

Ich schätze, dem Sicherheitsteam würde das wohl nicht gefallen.

[coremaker]

Vielleicht liegt es daran, dass ich schon ein alter Hase bin, aber braucht man das wirklich?

[cgl00]

Das scheint nützlich zu sein, wenn man auf einem Server webbezogene Experimente über localhost durchführt.

[coremaker]

Sie meinen wohl, wenn man etwas lokal lösen und vor dem Deployment testen möchte, oder?
Arbeiten an einem entfernten Ort, wenn der Zugang zum internen Netzwerk schwierig war und die Umgebung eingeschränkt war...

[t7vonn]

Wenn man in iTerm mit term.everything iTerm öffnet ... geht das dann?

[GN⁺]

Hacker-News-Kommentare

• Ich halte das für ein völlig nutzloses und zugleich großartiges Projekt, irgendwo an der Grenze zwischen Programmierung und Kunst; ich glaube, dieses Projekt war eine ausgesprochen unterhaltsame Lernerfahrung, und ich möchte einfach sagen: wirklich gut gemacht.
  • Ich glaube nicht, dass es zu 100 % nutzlos ist; es könnte für Apps nützlich sein, die in Docker-Containern laufen. Normalerweise gibt es Wege, GUI-Apps in Containern zu starten, aber das hier könnte einfacher sein. Allerdings ist das Ausführen von GUI-Apps in Docker überraschend einfach. Ich werde morgen anhand dieser Anleitung testen, ob es funktioniert, und frage mich, ob es auch unter Windows läuft.
  • Es ist schwer zu erklären, warum mich dieses Projekt so glücklich macht, aber auch wenn ich es vermutlich nicht oft tatsächlich nutzen würde, bekomme ich allein beim Gedanken daran ein albernes Grinsen ins Gesicht.
• Das ist ein Projekt, bei dem man das Gefühl bekommt, es gäbe keine Grenzen; ein wirklich großartiges Ergebnis, mit dem man endlos angeben möchte. Ich finde es beeindruckend und es bringt mich im Team dazu, darüber nachzudenken, wie wir VDI künftig umsetzen sollten. Es verleiht dem Ausdruck „ghost in the shell“ irgendwie eine neue Bedeutung. Und nebenbei frage ich mich, ob man darauf auch Doom ausführen kann.
  • Falls du dich das fragst: Man kann sich hier ansehen, wie Doom läuft. Ich habe ein paar Zeilen geändert, damit es funktioniert, weil term.everything Eingaben nur von stdin annimmt. Über SSH ist es mit verschiedenen Terminals recht gut kompatibel.
    1. Ich habe die Control-Taste auf eine andere Taste gemappt, da sie ursprünglich zum Senden von Signalen gedacht ist.
    2. Ich musste das Eingabe-Timeout anpassen. stdin-basierte Eingabe bekommt nur keydown-Events, aber keine keyup-Events. Deshalb muss man raten, wann der Benutzer die Taste losgelassen hat. Normalerweise kann man keyup sofort senden, aber bei Doom musste ich wegen des Key-Debounce-Verhaltens etwa 50–100 ms warten. Um sich im Spiel nach vorne zu bewegen, hält man normalerweise die Pfeiltaste nach oben gedrückt, aber bei der jetzigen Methode muss man sie wiederholt drücken, was etwas unpraktisch ist; trotzdem läuft es und ist spielbar.
  • aaquake lief schon vor solchen Projekten in einer ASCII-Terminalumgebung.
• Ich finde dieses Projekt wirklich großartig. Persönlich denke ich, dass es auf Wayland-Basis noch viel mehr solcher interessanten Anwendungsfälle geben wird. Ich interessiere mich auch für Projekte wie greenfield.
• Als ich damals beim carbonyl-Projekt gesehen habe, wie Chromium im Terminal lief (hier zu sehen), war ich völlig begeistert, aber inzwischen wird es nicht mehr gepflegt. Dieses Projekt wirkt wie eine noch einmal gesteigerte Version dieser Idee, und ich halte das Ergebnis aufrichtig für großartig.
• Ich finde, bash_completion sollte wirklich so gestaltet sein, dass es extrem einfach zu benutzen ist. In der Praxis ist es schwieriger zu schreiben, als man denkt; selbst einfaches Copy-and-Paste ist umständlich. Clevere Entwickler bauen Apps von Anfang an so, dass sie gut mit bash_completion harmonieren. Wenn zum Beispiel das erste zentrale Argument bash-freundlich ist, kann man mit einer Struktur wie mycli myfunc ... per Tab sofort alle Funktionen entdecken. Neue Funktionen müssen dann nicht extra beworben werden. Und wenn man etwas nur aus der Completion entfernt, lassen sich Funktionen auf natürliche Weise auslaufen, ohne bestehende Skripte kaputtzumachen. Am Ende landet dann alles in der CLI, einfach weil es schon jemand vorbereitet hat.
• Wenn man wie ich auf Build-Maschinen gelegentlich direkt auf einen Desktop oder Browser zugreifen muss, sind VNC oder andere Desktop-Sharing-Methoden oft unpraktisch oder sicherheitstechnisch problematisch. Ich denke, dieses Projekt könnte in solchen Situationen eine große Hilfe sein.
• Ich halte das für ein wirklich brauchbares Projekt. Für einmalige Remote-Aufgaben scheint es gut geeignet zu sein. Ich weiß nicht, wie es mit dem Remote-Anhängen an laufende Programme, dem späteren Trennen oder dem Bildschirm-Mirroring aussieht, aber es wäre praktisch, wenn man sich per SSH mit einem Desktop verbinden und einen bereits laufenden Client wie Discord steuern könnte. Übrigens würde ich mir in dem Zusammenhang auch gern RDP-Funktionen für das Starten entfernter Apps ansehen.
  • Man könnte auch einfach einen Discord-Client für die CLI verwenden oder einen IRC-Client starten, der sich mit einem Bitlbee-Server verbindet.
• Ich sollte mir wohl notieren, dass es <i>im Terminal</i> ist; ich muss mich selbst daran erinnern, dass das vermutlich nicht im Textmodus funktioniert.
  • Aber war nicht das erste Beispiel, also das Comic-Beispiel, im Textmodus?
• Ich wünsche dem Projekt eine kontinuierliche Weiterentwicklung; hoffentlich kommt es niemals zum Stillstand.
• Ich finde das wirklich beeindruckend! Es wird sicher viele ganz eigene Anwendungsfälle geben, aber für mich wäre es besonders spannend, VSCode auf dem iPad zu betreiben. Hoffentlich wird eines Tages auch iPadOS unterstützt.
  • Für Remote-Entwicklung reicht mir normalerweise code-server völlig aus.
  • Da es SSH-Clients für das iPad gibt, denke ich, dass es möglich sein sollte. Ich habe vor, es gleich auszuprobieren.