Terminal.Gui is a .NET UI framework for cross-platform terminal apps. It started life as gui.cs, created by Miguel de Icaza. Miguel, being Miguel, casually dropped a complete cross-platform console UI stack into the world, made it just great enough to be dangerous, and moved on.
I was submitting fixes to, and poking around in gui.cs, when Miguel became enamored with Swift. I asked him if I could take it over. I wanted the experience of maintaining a real OSS project at scale. My previous open-source efforts (like WinPrint) were solo affairs where I was not only the only developer, but pretty much the only user. Nobody really cared.
Terminal.Gui, on the other hand, had traction. Devs were using it, and I was itching for something to tinker with that would scratch three long-running obsessions: fixed-pitch fonts, the command line, and UI frameworks.
I have a thing for fonts—especially monospace ones. When Microsoft released Cascadia Code, I needed to see it sing. Just staring at it in VS Code wasn’t enough, so I rewrote WinPrint. That helped. But not enough.
I grew up on the command line and have spent an embarrassing amount of time customizing shells and re-learning bash, CMD, and PowerShell magic incantations. It’s a lifestyle. And don’t even get me started on UI frameworks. The Windows vs. OS/2 battle was MY battle. I wrote some of the earliest Windows shareware and forgot more about Win32’s USER subsystem than most people will ever know.
Fast forward to today: Terminal.Gui has become a vibrant project with over 10,000 stars on GitHub and a growing community of contributors and users. We’re approaching alpha on v2, a massive refactor grounded in a real architecture. We added layout and style engines, modernized input handling, and built a system that doesn’t collapse when someone blinks at it sideways. It’s still absurd—but it’s cohesively absurd.
Along the way, we kept bumping into a familiar problem: How do you let consumers customize or override behaviors without forcing them to subclass everything? That’s where the Cancellable Work Pattern (CWP) came from.
CWP fell out of the code. We were solving real-world framework problems and suddenly this pattern kept appearing: structured phases of work, cancellable, interceptable, with optional hooks. Eventually I gave it a name, formalized it, and wrote it up.
Is it novel? Probably not. It’s a mashup of things you’ve seen—Template Method, Observer, pipelining, events-with-cancel args—but it works well in a UI framework. I’m proud of how clean and extensible it’s made v2.
If you’re a real CS person (or just play one on GitHub like me), I’d love your critique. Go read the CWP deep dive and tell me what’s wrong with it. Or what’s obvious. Or what I should’ve done differently.
This project has been weirdly validating. I have a BS in Systems Engineering, Software Option. But I’ve never felt like a real developer—not compared to the brilliant minds I’ve worked with: Curt Palmer, Todd Laney, Henry Sanders, Anders Hejlsberg, Jeffery Snover, Bob Atkinson, Jim Gray, David Weiss, Jim Lyon, and more. I have massive impostor syndrome.
But somehow, I ended up maintaining a terminal UI framework in 2025. It’s ridiculous. And wonderful. And brings me joy.
If you think it’s cool, confusing, or just plain dumb, leave a comment. I’m all ears.
RSS - Posts