A pane can't hold a GUI app
The workaround is streaming pixels through terminal escape sequences — which needs a capable host terminal and costs a readback every frame.
A Linux distribution proposal · prototype stage
What if the desktop were shefrd?
shefros proposes an Arch-based Linux distribution whose desktop session is shefrd: every Super key a shefrd action, every window a pane. A pane could hold a terminal, a browser or a game. Today, the part that exists is the proof underneath it — pinning a real GUI window into a pane, and checking it's actually drawn there.
$ npm run dev ready on http://localhost:4321 GET / 200 4ms GET /styles.css 200 1ms GET / 200 3ms
619,14 661×226 · visible
$ shefros-pin $SOCK w1:p2 8 --once
w1:p2 -> 619,14 661x226 got 619,14 661x226 match=True inside_host=True
An illustration of the idea: shefrd owns the layout, and a browser window sits in pane w1:p2 like any terminal would. The pinned-window output is the real line recorded in the prototype's verification.
Why
The last ceilings come from someone else's desktop.
shefrd dissolved the limits of being a guest inside someone else's terminal. The ones that remain come from being a guest inside someone else's window manager.
Super never arrives
shefrd can parse, decode, match and map Super from two keyboard protocols. The path has never been fed once, because the window manager takes the key first.
“Workspace” means two things
shefrd's spaces and the desktop's workspaces compete for the same word and the same keys. In shefros there would be one.
What exists today
Three tools that prove the idea before building it.
Small Python programs, each honest about what it can and can't establish.
shefros-pin
Holds a window at a shefrd pane's rect. shefrd owns the layout; the compositor only places what it's told. Placement is confirmed against the client's own window rect, not the compositor's intent.
shefros-pin <shefrd-api-socket> <pane-id> <sway-con-id> [--once]
- 0 the client's rect matches the pane, inside the host
- 1 placement didn't settle
- 2 layout, host or pane unavailable
shefros-visible
Geometry isn't visibility: an occluded window reports a perfect rect. So it hides the window and looks again — if the pixels don't change, nothing of it was on screen.
shefros-visible <con-id> <x> <y> <w> <h>
- 0 visible
- 1 not visible
- 2 inconclusive, with the reason
shefros-demo
Drives shefrd through its public CLI in a throwaway session: two spaces, split panes running commands, three demo agents reporting their state — and one of them really fixes a failing test. Then it deletes everything it made, by name.
shefros-demo [--show] [--pace SECONDS] [--hold SECONDS] [--report FILE]
- ✓ never touches your own herd unless you ask with
--show - ✓ tests assert the scene was built and nothing survived it
Measured, not assumed
A placed window isn't a seen window.
A browser once sat invisible behind the terminal while every geometry check said it was placed correctly. The visibility check tells the three cases apart:
| Case | Result |
|---|---|
| Pinned and raised | visible=True · delta 213.6 |
| Occluded by the host window | visible=False · delta 0.0 |
| Parked in the scratchpad | inconclusive · window is in the scratchpad |
$ shefros-pin $SOCK w1:p2 8 --once && \ shefros-visible 8 619 14 661 226 w1:p2 -> 619,14 661x226 got 619,14 661x226 match=True inside_host=True visible=True mean_pixel_delta=213.6 threshold=8.0
Recorded in the prototype's verification, nested sway 1.7 on WSLg at 1280×720. Raise the host window over the pinned one and geometry still says match=True — but the pixel delta collapses to 0.0 and the verdict flips.
- A terminal resize changes every pane rect and emits no event, so pinning polls.
- A new window re-tiles the layout before it can be floated, so floating is a rule applied on arrival.
- Cell size falls out of the host window's pixel rect: 1280/182 = 7.03 and 720/51 = 14.12 against a measured 7×14.
Status
A proposal with a working proof underneath.
shefros isn't an installable distribution or a desktop session yet. Nothing here should be read as one.
Run the prototype
# needs sway, grim, python3 with Pillow, and a running shefrd bin/shefros-pin "$SHEFRD_SOCKET" w1:p2 <sway-con-id> --once bin/shefros-visible <sway-con-id> <x> <y> <w> <h> bin/shefros-demo --show # needs only shefrd and python3
Set SHEFROS_WAYLAND_DISPLAY when the compositor under test isn't the one your shell is connected to. Continuous pinning installs a broad window rule: use it only in an isolated test compositor.