Tessel

Tessel is the window manager I am building for my own Mac. I use the keyboard to move between windows and workspaces. I wanted to question how that should work, including choices that other window managers treat as normal.

It is written in Swift for Apple silicon and macOS 27 or later. The current version has ten workspaces, remembered rails of tiled windows, and a floating layer for each workspace. It works without a configuration file. The CLI is mainly for agents to inspect windows and explain why each one tiles or floats.

I add features as experiments. Each starts behind a configuration flag and gets used on the real system. If I keep it, I remove the flag. If I reject it, I remove the code. Matching another window manager's feature list is not a reason to keep something.

Hiding a window is real work

An inactive workspace needs somewhere to put its windows. Minimizing took about 600 milliseconds in the local probes. Parking windows just outside the display left a visible strip and let applications keep drawing. Hiding a whole application could not separate its windows across workspaces.

I chose an invisible native Space through Apple's private SkyLight framework. Moving a window into it took roughly 2.5 milliseconds in the probes, and macOS treated the window as hidden. Tessel returns those windows to the desktop when it quits normally.

Using a private framework has a cost. Apple can change it. I keep that code behind one hide-and-show boundary and verify it against the supported system. A missing method disables the feature with a visible reason.

The animation I threw away

The first animation moved real windows through the Accessibility API on each frame. I rejected it twice. A short spring jumped too far between frames. A longer curve gave me more time to see the jerks and the windows moving out of step. Applications also rearranged their content during the motion.

The replacement moves screenshots in Tessel's own overlay. Underneath, it places each real window once. The default motion lasts 250 milliseconds, then the overlay gives way to the real windows. Resizing crops the old capture while waiting for the new one, so text does not stretch. Without Screen Recording permission, or with Reduce Motion enabled, changes are instant.

That approach had its own failure. After a day, motion started much later than it had in the demo. Capturing a window that had stopped drawing could leave a recording attribution in macOS after the process was gone. Those entries accumulated and made later captures slower.

Tessel now checks that a window is drawn before capturing it and stops waiting when a capture times out. A window can still close after the check. I have narrowed that race, but the remaining behavior depends on macOS.