Did you try out using I3's scripting capabilities before setting out to reinvent that wheel? That's the route I'm current on right now, but we seem to be kindred spirits. Discovering IPC has mostly quelled my urge to reinvent wheels. Emacs can easily be communicated with and controlled from Ruby, and I'm still figuring out the right approach to interop with Firefox. I think eventually I'll just use a terminal from inside of Emacs.
Both i3wm and bspwm. I must admit part of it was probably the fun of it, but the main consideration was a number of small nuisances.
E.g. I prefer the minimalism of bspwm to i3wm, but bspwm insists on placing a window that has _NET_WM_WINDOW_TYPE_DESKTOP on all desktops. That follows the EWMH spec, and makes sense for a floating wm, but not for a tiling one - if you use a file manager you end up with a file manager that expects to be able to open floating windows all over the place behind all your tiling windows on your tiling desktops too. There are other wm's that deviate on this - e.g. Katriawm does it the way I prefer for this specific case.
(Basically I want one or more floating desktops, and the rest tiling; on the floating desktops I want a file manager that is always at the bottom of the stacking)
I'm sure it's reasonably easy to fix, but there were more nuisances like that, and when I started digging into the bspwm codebase to consider fixing that and a few other issues (e.g there's no trivial way of making all windows on a specific desktop floating without running a script that waits for events, which means you often get "flashes" when windows opens first in tiling mode before being modified), I realised it was a toss-up whether being stuck fixing issues in a code base that size would be more enjoyable than just writing one from the scratch.
My wm is currently ~680 lines of Ruby, with no dependencies at all on native extensions (the X11 gem I extended from an abandoned starting point speaks directly to the X server with no Xlib involved). Bspwm's IPC support alone is 2KLOC, it's layout tree support is 2.3KLOC. There are many more files.
This is not to criticise it - it's very clean for C, and has far more capabilities than my wm will ever get because have no interest in adding much. i3wm similarly is very clean code, but it's also "big" and complex.
When I started building my own, I rewrote tinywm from C with this hacky little thing[1] and then just iterated. That's how little it takes for the bare minimum floating wm - ironically making a decent tiling wm takes far more code than floating - both bspwm and i3wm spend a considerable amount of code on their tree management.
I have nowhere near parity with bspwm, but I'm ~90% there in terms of the functionality I use, and so don't have to deal with several of the little annoyances I wanted to fix in bspwm.
I expect mine to grow a bit, but not much, because I have no intention of catering to "the general public" (of tiling window manager users, so all 12 of us) - I'll split out anything that is generic enough in gems, so that it may be of help to anyone else who wants to go down the same path, but I see these projects of mine as being my configuration. As such they'll be extremely opinionated, and rude about it. Generic stuff will be torn out, step by step, until all that is left is the bits specific to me.
With respect to the IPC, I'm fully with you that having IPC helps and I wish more tools embraced minimalism based on cooperating scripts. My entire environment is focused on composability via IPC or spawning separate scripts controlled via pipes. My file selector, theme selector, and buffer selection in my editor all call out to scripts that default to using rofi for example. It's also the only reason I didn't replace my WM many years ago.
Ironically both i3wm and bspwm reinvented the wheel on that one, when most of their needs can be met with even just XSendEvent, and the rest can be met with selections. My wm doesn't need a special client because any client like xdo etc. that can trigger XSendEvent works.
The complexity of the existing options and my config is the same thing that led me to write my own editor - Emacs is far more capable, but I only ever used 1% of that, but to try to shape Emacs into what I wanted I ended up with a bunch of elisp packages and a couple of thousand lines of my own config. My own editor, on the other hand, is ~4k lines that I know inside and out and so it's far easier for me when I want to tweak my workflow (incidentally it's also heavily IPC based - all buffers are held in a separate process and frontends operate on that, so each frontend only know how to show a single file because you can just attach another frontend with a single key-combo so why bother supporting multiple windows or spltis)
Similar thing with Polybar, which I mostly replaced in anger last night because it was less effort to write my own (<100 lines) workspace switcher than to get Polybar to build with the new EWMH based switcher module on my system. Too many tools are too big and complex.
Of course, had I not enjoyed coding for the sake of it, I would have made do. I do feel my resulting environment is nicer and more productive, but not enough to justify embarking on this rewrite spree if it wasn't fun too.
Thanks for this writeup, I really appreciate it! I love coding too, but not enough to do it in my off time, my body screams at me too much, but I was recently released from my corporate job where I had to use MacOS so now I can spend more time on it now. Never taking another job where I can't control my computing environment.
Someone was watching me work in a bar and saying he'd pay for software that could help him do all that. I could only laugh.
I do end up using a lot of Emacs' functionality, and will more likely just use it's shell functionality when I feel the need to learn how it works. If I do end up rewriting something it would be a browser, I think. Webkit is annoying but maybe not as annoying as Firefox. Can't be too hard to wrap Ruby around it and make something basic.
I'd love to see clean Ruby bindings for a modern browser engine - I don't really care which... Being able to customise it more easily would be fantastic..
