The Problem

Developers who need to run graphical Linux applications inside an SSH session or a low‑bandwidth terminal have to resort to X forwarding, VNC, or custom image‑streaming tools. Those solutions add latency, require extra servers, and often break with Wayland‑only apps. A single binary that renders a Wayland compositor directly to ANSI/kitty graphics would eliminate the extra stack.

What This Does

term.everything❗ implements a lightweight Wayland compositor in Go that captures window buffers and translates them to terminal‑compatible image protocols. The core lives in the wayland/ package (≈ 80 files) which defines the protocol implementation, surface management, and input handling. The termeverything/ package (≈ 18 files) drives the main loop, parses CLI arguments (ParseArgs.go), and renders frames (TerminalDrawLoop.go, RenderMarkdownToTerminal.go). The small framebuffertoansi/ helper converts raw framebuffer data to ANSI/kitty graphics (ChafaInfo.go, DetectTerminal.go). The entry point is main.go which calls MainLoop in termeverything/MainLoop.go.

How It Is Wired

Execution starts at main in main.go (line 9). It creates the Wayland socket (MakeSocketListener), launches the compositor (Client.go), and enters MainLoop.

  • MainLoop → AddObject, GetGlobalBinds, GetWlSurfaceObject (defined in wayland/types.go and wayland/Client.go). These functions are the most widely referenced (18–15 call sites each) and thus constitute the high‑impact core.
  • Input events flow through PointerCode.go (ParseMouseCode → MouseModifiers) and ConvertKeycodeToXbdCode.go, both showing high branching density (≈ 57 branches/203 lines).
  • Rendering is performed by TerminalDrawLoop.go, which repeatedly calls RenderMarkdownToTerminal → renderCode. The draw loop eventually invokes framebuffertoansi/ChafaInfo.go to translate the compositor’s buffer into a terminal image.
  • Filesystem interaction is limited to a single cleanup call: removeFileIfExists (via os.Remove) in the socket‑setup path. No network or database accesses are present.
  • The two protocol generators (wayland/protocols/wayland.xml.go and xdg-shell.xml.go) each contain > 2,800 lines and define the bulk of the Wayland object hierarchy (GetDelegate, OnRequest). Their size makes them change‑impact hotspots; any modification ripples through > 100 functions.
  • The call graph contains 534 internal edges; the most connected nodes (AddObject, GetGlobalBinds) are in wayland/types.go and wayland/Client.go. No circular imports were detected.

How To Use It

# Clone the repository
git clone https://github.com/moses-y/term.everything
cd term.everything

# Build the binary (Makefile provides a simple target)
make        # or: go build -o term-everything main.go

# Run a GUI app inside the terminal
./term-everything firefox   # example; any Wayland‑compatible app

The program reads its command‑line flags from termeverything/ParseArgs.go; default behavior requires no additional configuration files. The only external effect is the temporary Wayland socket file, removed by the cleanup step shown above.

Real‑World Use

A sysadmin can SSH into a headless server, launch term-everything firefox, and view the browser inside an iTerm2 or kitty terminal that supports the Kitty graphics protocol. The terminal acts as the display, eliminating X forwarding and reducing latency to a single image stream.

Code Health & Issues

  • HIGH – Deep nesting in ConvertKeycodeToXbdCode.go, StatusLine.go, TerminalWindow.go (max indent 8).
  • HIGH – Duplicated code across draw‑loop and protocol files (≈ 49 repeated 6‑line blocks).
  • HIGH – Oversized files wayland/protocols/wayland.xml.go & xdg-shell.xml.go (~2,857 lines each).
  • MEDIUM – High branching density in several files (57 branches/203 lines).
  • LOW – TODO/FIXME markers present in multiple source files.
  • HIGH – No test suite (90 source files, zero test files).
  • HIGH – No CI workflow (no .github/workflows).
  • MEDIUM – No Dependabot (single go.mod without automated updates).

The Bottom Line

term.everything❗ delivers a novel, Go‑based Wayland compositor that streams GUI windows to terminals, filling a niche for remote, low‑overhead graphical access. The codebase is functional but suffers from deep nesting, duplicated logic, and massive protocol files that hinder maintainability. Adding tests, CI, and refactoring the high‑impact modules would make it production‑ready for teams needing terminal‑native GUI rendering.