# A Wayland Compositor That Renders GUI Apps Inside a Terminal
By IO Digest Desk
A small open source project attracted broad developer attention with a blunt promise: run GUI applications inside a terminal. The project, `term.everything`, is described by its author as a Linux command-line program that runs GUI windows in a terminal rather than on a conventional display.[16124]
What makes the project notable is not simply that it shows images in a terminal. According to the project description, `term.everything` is a Wayland compositor built from scratch whose output target is the terminal itself instead of a monitor.[16124] That places it in a different category from terminal file viewers or remote desktop wrappers. The terminal becomes the display surface for general-purpose graphical software.
The demonstrations described in the repository outline the practical limits and the appeal. The rendered window quality depends on the number of rows and columns available in the terminal, and the author says that increasing terminal resolution can improve the image while potentially reducing performance.[16124] That tradeoff is central to the experiment: every extra unit of visual fidelity has to fit through the constraints of terminal rendering.
The repository presents several examples meant to show how far those constraints can be stretched. One example describes opening a movie and tuning quality to balance frame rate and resolution. Another says that terminals with image support, including Kitty and iTerm2, can render windows at full resolution, though the repository warns that performance may degrade.[16124] A separate example describes opening Firefox at full resolution by SSHing from iTerm2 on macOS into Ubuntu.[16124]
The project also frames itself as a rebuttal to the steady stream of specialized terminal viewers. The repository argues that instead of building dedicated viewers for every format, developers can use the graphical viewer they already have from inside the terminal.[16124] That is partly a joke and partly a design thesis. If the terminal can host a compositor, then the boundary between text-first and GUI-first workflows becomes less rigid.
The examples lean into that tension. The author says the software can run Doom with a small amount of extra hacking and can even run an entire desktop in a terminal.[16124] Another cited demo shows Firefox running on KDE Neon inside a virtual machine on Bobcat, still within the terminal pipeline.[16124] These are not ordinary productivity claims; they are stress tests for the concept.
Even so, the technical outline is concrete. The repository identifies the software as a Linux CLI program, says it is written primarily in Go with a small amount of C, and points readers to separate documentation for a usage guide and an explanation of how the system works.[16124] That signals a project intended for inspection and experimentation rather than a one-off demo.
The broader significance is that `term.everything` turns the terminal into a programmable graphics endpoint without pretending the result is frictionless. The repository repeatedly notes performance and resolution limits, especially when output is tied to terminal dimensions.[16124] But those limits are also part of the appeal. The project is a reminder that long-settled software boundaries can still be renegotiated by developers willing to rebuild familiar layers from scratch.
For terminal enthusiasts, the proposition is simple: if a compositor can speak terminal, the terminal no longer has to stop where text ends. `term.everything` is an early, eccentric demonstration of that idea, but it is precise enough to be more than a stunt. It is a working claim that the oldest developer interface on most systems still has room for new tricks.
