status-4

9 months since my last status update >.< sigh
I've been spending most of my time recently learning about wayland. Not only to have fun tinkering with my desktop environment but also because I have a big project I'm working on and wayland is at the center of it.

Wayland desktop

I had a bunch of stuff inside of my sway config that made it really difficult to WM-hop so I spent a bunch of time moving as much configuration out of sway itself. This mostly meant moving all daemons into systemd and installing kanshi. I didn't realize that swaylock and swayidle were misnomers and they could be used across many window managers.
I managed to get my sway config down to the essentials:

my sway cfg
I'm satisfied with my cfg for now. I plan to switch off of sway at some point and I'm having fun exploring the options. I think a dynamic tiling wm will be my next choice.
If anyone has any suggestions feel free to reach out. I'm looking for:

I built figbar as my first project in the world of wayland.
As I was looking around for a status bar, I had some features in mind that I really couldn't find in an other bar already available:

I don't want rainbow puke in my status bar, a single highlight color for emphasis should be it
zwlr_layer_shell_v1 so I can use it with any wlroots wm
stdin for the status bar values
stdout for the click events

I've been helping rockorager with his terminal emulator. It's a snappy little emulator that's built on top of libghostty.
As we were iterating on ideas on what to do with a terminal emulator, we started chatting about what the next terminal could look like.
Tim mentioned that there's no reason wayland couldn't support the next generation of terminals.

This is my next big project. Everyone is trying to recreate a multiplexer for agentic workflows and all of them are running into the same issues. They need to support windows, tabs, and splits with a single ansi bytestream built on ptys. It is fundamentally the wrong tool for the job. In fact, there are a bunch of reasons why the ansi bytestream of terminals is the wrong tool for many cli programs.
Here's the basic idea:

Wayland operates by sharing pixel buffers from clients to servers.
What if wayland could support sharing cell buffers? We could create an extension protocol that allows programs to share 2d text arrays. We could create text programs on the wayland tech stack. This also means we could leverage wayland for compositing terminal programs together without tearing or ansi byte corruption.
It also means we can free ourselves for the pty. Further, like xwayland, there's a clear path to supporting legacy programs with something like xpty.
Finally, we could create a mac gui app that reimplements a wayland compositor specifically for terminal programs.

I think it's such a cool idea and I've been having fun tinkering with the idea. I don't particularly care at this point to rush it out the door since this is just as much a learning exercise for me as it is something I want to exist in the world. I managed to vibe a working prototype mainly to prove that it is possible. Now I'm starting from scratch and writing it by hand. I'll share more details when I have something to share.