Term.everything - ターミナルであらゆるGUIアプリを実行する

• Linux向けのCLIプログラムで、GUIアプリケーションをターミナルから直接実行できる
• 独自実装のWaylandコンポジタを使い、モニターの代わりにターミナルへGUI出力を送る仕組み
• ssh環境でも実行可能で、Webブラウザー、ファイルマネージャー、さらにはDoomまでターミナル内で実行できる
• ターミナルの解像度（行数・列数）によって出力品質が変わり、iTerm2やkittyのような画像対応ターミナルではフル解像度レンダリングもサポート
• Typescriptとbunを基盤に開発され、一部C++コードも含まれており、現時点では一部アプリのみ対応だが、「Term everything❗」 を目標に拡張中

---

プロジェクトの重要性と優位性

• Term.everythingは既存のターミナル向けファイルビューアや単純な画像出力ツールと異なり、「あらゆる」GUIアプリケーションをターミナル内で実行できる
• SSHを含むネットワーク環境でもGUIインターフェースを利用でき、サーバー管理、リモート開発に強みがある
• kitty、iTerm2など最新ターミナルの画像機能を最大限活用し、解像度・フレームレート向上オプションを提供

概要

• Term.everythingはLinux CLIプログラムで、ターミナルでGUIウィンドウを直接実行できるのが特徴
• 独自開発のWaylandベースのコンポジタが中核で、通常のモニターの代わりにターミナルへGUIをレンダリングする
• x11、Waylandの両方をサポートし、ssh経由でリモートからも利用可能
• 限られたターミナルの行数・列数がウィンドウ品質に影響し、ターミナル解像度を上げることで品質改善が可能（ただし性能低下の可能性あり）

主な利用例

• ゲーム実行: ターミナル内でFontemonのようなゲームやDoom（シェアウェア版エピソード）を実行可能
• 動画再生: Wing It! の映像再生が可能で、解像度調整によってフレームレートと画質のバランスを設定できる
• ブラウザー実行: iTerm2 + ssh環境でUbuntuに接続し、Firefoxを実行可能
• ファイルビューアの代替: わざわざターミナル専用ファイルビューアを作らずとも、既存のGUIファイルマネージャーをターミナルで直接使える
• 再帰実行: ターミナルの中でさらに別のターミナルを実行する "terminal in a terminal"

動作原理と開発情報

• 基本概念

  • かつては、プログラムが画面に何かを描画するにはRAMの特定領域へ直接書き込むことができた
  • 現代のシステムでは**ディスプレイサーバー（Display Server）**が入出力を管理し、マウスやキーボードのような入力とグラフィック／画像出力を調整する
  • Linux環境では主にWaylandプロトコルまたはX11が使われ、Term.everythingはWaylandを基盤に動作する

• Waylandプロトコル

  • Waylandはディスプレイサーバーそのものではなく、サーバーとプログラム間の通信を定義するプロトコル
  • プログラムは自前でレンダリングした結果をディスプレイサーバーに渡し、サーバーがそれを画面へ出力する
  • 重要なのはレンダリングモデルが強制されないこと → プログラムは望む方法で描画できる
  • そのため、出力結果を画面ではなく別の場所（例: ターミナル）へ送ることも可能

• Term.everythingの出力処理

  • Waylandクライアント（実行中のGUIアプリ）が描画した画像を受け取り、ターミナル文字出力へ変換する
  • 変換プロセス:
    • 1. クライアントから渡された画像データを受信
    • 2. これをUTF-8文字 + ANSIエスケープコードへ変換
    • 3. 変換にはchafaライブラリを活用し、ピクセルをターミナル文字へマッピング
  • 入力はstdin経由で渡されたキーボード、マウスイベントをWaylandクライアントへ転送

• 実装の詳細

  • 中核アイデアはシンプルだが、実際の実装には約1万行超のコードが必要
  • Typescript（bunベース）と一部C++で書かれており、カスタムWaylandディスプレイサーバーとして機能する
  • ソースコードは src/ ディレクトリ で確認可能

• 拡張可能性

  • Term.everythingは単にターミナルでGUIを実行するだけにとどまらないことを目指している
  • Waylandベースのカスタムディスプレイサーバーを使って、別の実験的なアイデアも実装できる可能性がある
  • 例: 出力デバイスをターミナルではなく、まったく別の媒体（例: プリンター、物理アート作品など）へ接続する活用

[iolothebard]

さらに屋上屋を架す

[ifmkl]

こういうのこそ本当にギークっぽいですね（笑）

[hybridego]

なぜ私だけロゴしか表示されず、動かないのでしょうか??

[bus710]

私は会社のMacで個人のMacを操作するのにSynergyを使っていたんですよね。今は個人のMacを手放してLinuxだけを使っているので、ワークフローが面倒になりました。

でもこのツールを使えば、会社のMacのターミナルから個人のLinuxデスクトップに接続して、いろいろな作業を自由にできるということですね？

やはりセキュリティチームは嫌がりそうです。

[coremaker]

私も古参なのでそう感じるのかもしれませんが、これって必要ですか？

[cgl00]

サーバーでWeb関連の実験（localhost経由）を行うときに便利そうです

[coremaker]

ローカルで解決して、デプロイ前にテストしたいという話ですよね?
リモート先での作業、内部ネットワークへの接続が難しく制約の多い環境だったとき…

[t7vonn]

iTermの中でterm.everythingを使ってiTermを開いたら……どうなるんですか？

[GN⁺]

Hacker Newsのコメント

• 本当に役に立たないのに素晴らしいプロジェクトだと思う。プログラミングと芸術の境界に立っていて、このプロジェクトはとても楽しい学習体験だったはずだし、本当によくやったと言いたい。
  • 100% 役に立たないわけではない気がする。Dockerコンテナ内で動くアプリには有用かもしれない。普通はコンテナ内でGUIアプリを表示する方法があるけれど、こちらのほうが簡単な可能性もある。ただ、DockerでGUIアプリを動かす方法も思ったより簡単だ。このガイドを参考にして明日試してみるつもりで、Windowsでも動くのか気になる。
  • なぜこのプロジェクトがこんなに自分を幸せにするのか説明しにくいけれど、実際に使う場面は多くなさそうなのに、これを思うと間抜けな笑みがこぼれる。
• これは限界がどこにあるのかわからなくなるようなプロジェクトだ。本当に素晴らしく、無限に自慢したくなる成果物だと思う。すごいと感じるし、チームで今後VDIをどう実装すべきか考えさせられる。ghost in the shell という言葉に新しい意味を与える感じだ。ところで doom も動くのだろうか。
  • 気になるなら、doomの実行例を確認できる。term.everything が入力を stdin からしか受け取らないので、数行修正して動かした。ssh 経由でさまざまなターミナルとの互換性が高い。
    1. Control キーを別のキーにマッピングした（元はシグナル送信用）。
    2. 入力タイムアウトを調整する必要があった。stdin ベースの入力では keydown イベントしか受け取れず、keyup イベントは発生しない。そのため、ユーザーがいつキーを離したかを推測しなければならず、普通はすぐ keyup を送ってもよいが、doom ではキーデバウンス処理のため 50〜100ms ほど待つ必要があった。ゲームで前進するには通常は上矢印キーを押しっぱなしにすればいいが、今の方式では繰り返し押す必要があるので少し不便ではあるものの、実行もプレイも可能だ。
  • aaquake は、この種のプロジェクトより前からすでに ASCII ターミナル環境で動いていたゲームだ。
• このプロジェクトは本当に素晴らしいと思う。個人的には、Wayland ベースでこうした面白いユースケースがもっと増えそうだと感じる。greenfield プロジェクトにも興味がある。
• 以前、carbonyl プロジェクトで chromium をターミナル上で動かすのを見たときは本当に興奮した（参考）。ただ、今はメンテナンスされていない。今回のプロジェクトは、そのアイデアをさらに一段進めたように感じる。心から素晴らしい成果だと思う。
• bash_completion は本当に簡単に使えるようにすべきだと思う。実際には思ったより書くのが難しい。単純なコピペでさえ面倒だ。賢い開発者は最初から bash_completion と相性のよいアプリを作る。たとえば最初の重要な引数が bash フレンドリーなら、mycli myfunc ... のような構造だけで Tab キー一発ですべての機能がすぐわかる。新機能も宣伝する必要がない。completion から外すだけで既存スクリプトを壊さずに自然に機能を廃止できる。結局、誰かがすでにそうしてくれているおかげで、CLI にあらゆるものが詰め込まれることになる。
• 自分のようにビルドマシンでたまにデスクトップやブラウザへ直接アクセスして作業する必要がある場合、vnc やその他のデスクトップ共有方式は実用的でなかったり、セキュリティ上の問題があったりする。このプロジェクトはそういう状況で大いに役立つと思う。
• 本当に実用的なプロジェクトだと思う。リモートで単発の作業をするときにはよさそうだ。実行中のプログラムにリモートから接続して再び切り離すことや、画面ミラーリングの部分はよくわからない。SSH でデスクトップに接続して、実行中の Discord のようなクライアントを操作できるなら便利そうだ。参考までに、リモートアプリ実行に関する RDP の機能も見てみたい。
  • CLI 用の Discord クライアントを使うか、Bitlbee サーバーにつながる IRC クライアントを動かしてみるのもよさそうだ。
• <i>ターミナルで</i> という点をメモしておこう。これはテキストモードでは動かなさそうだと自分に言い聞かせている。
  • でも最初の例（漫画の例）はテキストモードではなかったっけ。
• プロジェクトの継続的な発展を願っている。絶対に止まらないでほしい。
• 本当にすごいと思う！ それぞれに独特なユースケースがあるだろうけれど、自分としては iPad で VSCode を動かす用途に期待している。いつか iPadOS もサポートされるといいな。
  • 自分はリモート開発にはたいてい code-server を使っていて、それで十分だと感じている。
  • iPad 向けの ssh クライアントがあるので、可能だと思う。今すぐ試してみるつもりだ。