# GUIアプリをターミナル内に描画するWaylandコンポジター
執筆：NeoTechNews編集部
発生日である2025年9月9日、小規模なオープンソースプロジェクトが、「GUIアプリケーションをターミナル内で動かす」という率直な触れ込みで開発者から幅広い注目を集めた。`term.everything`というこのプロジェクトは、従来型のディスプレイではなく、ターミナル内でGUIウィンドウを実行するLinuxコマンドラインプログラムだと作者によって説明されている。[16124]
このプロジェクトが注目に値するのは、単に画像をターミナルに表示するからではない。プロジェクトの説明によれば、`term.everything`はゼロから構築されたWaylandコンポジターで、その出力先はモニターではなくターミナルそのものだ。[16124] この点で、ターミナル用ファイルビューアーやリモートデスクトップのラッパーとは異なるカテゴリーに属する。ターミナルが汎用グラフィカルソフトウェアの表示面になるのだ。
リポジトリで説明されているデモは、実用上の限界と魅力の両方を明らかにしている。描画されるウィンドウの品質は、ターミナルで利用可能な行数と列数に左右される。作者によれば、ターミナルの解像度を上げれば画質を改善できるが、パフォーマンスが低下する可能性がある。[16124] このトレードオフが実験の中心だ。視覚的な忠実度を一段高めるたびに、ターミナル描画の制約内に収めなければならない。
リポジトリでは、こうした制約をどこまで押し広げられるかを示すため、複数の例を紹介している。一例では、映画を開き、フレームレートと解像度のバランスを取るよう画質を調整する方法が説明されている。別の例では、KittyやiTerm2など画像表示をサポートするターミナルなら、ウィンドウをフル解像度で描画できるとしているが、リポジトリはパフォーマンスが低下する可能性を警告している。[16124] さらに別の例では、macOS上のiTerm2からUbuntuへSSH接続し、Firefoxをフル解像度で開く方法が説明されている。[16124]
このプロジェクトは、次々と登場する用途特化型のターミナルビューアーに対する反論としても自らを位置付けている。リポジトリは、形式ごとに専用ビューアーを構築する代わりに、開発者がすでに持っているグラフィカルビューアーをターミナル内から使えばよいと主張している。[16124] これは一面では冗談であり、一面では設計思想でもある。ターミナルがコンポジターをホストできるなら、テキスト優先とGUI優先のワークフローの境界はそれほど固定的ではなくなる。
各例は、その緊張関係をあえて強調している。作者によれば、このソフトウェアは少し追加で手を加えればDoomを実行でき、デスクトップ環境全体さえターミナル内で動かせる。[16124] 別のデモでは、Bobcat上の仮想マシン内にあるKDE NeonでFirefoxを実行し、それもなおターミナルの処理経路内に収めている。[16124] これらは通常の生産性に関する主張ではなく、この概念に対するストレステストだ。
それでも、技術的な概要は具体的だ。リポジトリは、このソフトウェアをLinux CLIプログラムと位置付け、少量のCと主にGoで書かれていると説明し、利用ガイドとシステムの仕組みの説明について、それぞれ別のドキュメントを案内している。[16124] これは、一度限りのデモではなく、検証と実験を意図したプロジェクトであることを示している。
より広い意味では、`term.everything`は、その結果に一切の不便がないかのように装うことなく、ターミナルをプログラム可能なグラフィックス出力先へと変える。リポジトリは、特に出力がターミナルの寸法に縛られる場合のパフォーマンスと解像度の制約に繰り返し言及している。[16124] しかし、そうした制約も魅力の一部だ。このプロジェクトは、長年確立されてきたソフトウェアの境界であっても、おなじみのレイヤーをゼロから再構築しようとする開発者によって、なお引き直すことが可能だと思い起こさせる。
ターミナル愛好家にとって、その命題は単純だ。コンポジターがターミナルと通信できるなら、ターミナルはテキストが終わる場所で止まる必要はない。`term.everything`はこの発想を示す初期の風変わりな実例だが、単なる曲芸以上のものとなるだけの具体性を備えている。ほとんどのシステムで最も古くからある開発者向けインターフェースにも、まだ新しい工夫の余地があることを、動作する形で主張している。
