I have always had this huge problem, probably because of a rather crippling perfectionism that I have, where I want to do these huge projects, get started, and get discouraged and give up before really getting anywhere. This kinda sucks, I think everyone has this at some point, but for me it's nearly constant. And I *really* want to change that. bunbar was the first personal project I've finished in a *long* while (although, to be fair I did take a 2 year break from regular life to serve in Brazil). And honestly? It was a lot of fun. It took maybe a month or two of working on it on and off. And I think that what made this project work was really simple.
1. The scope of the project was reasonable, as I'll explain below
2. The project solves a real problem I actually have
3. The solution was both tractable and definable
Many of my projects, funny as it seems, fail to meet all three of these points. I'm very idealistic about how software should be, and I get caught up in these grand ideas about how I can make the "perfect" x and it really isn't helping anyone, least of all me.
So now, bunbar. I've been frustated for a while by the lack of good, simple status bars on wayland. The simple bars seperated the actual status info from the rendering, and the ones that include both are super complex. Not to mention, the appearance of the simple status bars was somewhat lacking, for me. So I decided it'd be cool to try and write my own. From scratch. I'd also never learned much about the wayland protocol before so this would be a good way to learn some new tech.
Scale-wise, while it was a LOT of work/learning, the end goal was simple and easily defined. One thing I made sure of at the start was to limit my design. I had a couple of things I wanted, and promised myself I would actually adhere to YAGNI. Also, because I'm solving a problem actually important to me (small though it may be), I actually was motivated to finish it. I ended up using hare to write this program, which I think was a pretty good choice. Hare has native wayland bindings which made that part really simple. I just had to learn the protocol and off I went. I also ended up trying to minimize the size of the final binary as much as possible. I wanted the entire program, with all of its dependencies, to be bundled together in a single binary. This forced me to do some creative things with rendering/fonts and icons, which were fun to figure out. And the final binary clocks in at 555KiB, with no other assets or dependencies (obviously, not including os interfaces, my specific window manager, etc.).
I think the coolest part I built was a way to get up-to-date audio information. My system uses pipewire, and I *really* wanted to avoid linking to other libraries. Not to mention that I *also* would have to learn the pipewire API. I actually did look into this at the start, but very quickly gave up when I realized that wpctl (a tool that does *almost* what I want) is several thousand lines of code. I wasn't really in the mood for that. Eventually I realized, though, that the volume info for my computer was only going to change *if I changed it*. It's not like any other resource I'd been monitoring up to this point, that has to be polled. Because I was already integrating with my window manager, I had been using sockets to monitor state and react to it. So what I decided to do was open a unix socket, and bind my volume keys to run wpctl and send the output to that socket. Kindy hacky but it worked pretty well, and I thought it was cool.
It's only like 1k SLOC too, which is both cool and kinda embarrassing that it took me almost a month to write a program this simple. But, at least it's done now. Today I fixed the final bug (that I'm aware of at least), which was a double free occuring very inconsistently and unpredictably. I eventually isolated it to my string interner (which for reasons I accidentally also made it an ARC). And basically my counting was really off. So I fixed that and it should be good from here on out. There's very few heap allocations and the others I've already checked so I think at least on the memory side I should be home free.
I think my final takeaway is that I need to focus my project on solving problems. That's technically what I've always done but they've never been well defined, and they were always more general projects, things I thought would be cool to do. I still think they'd be cool, but I definitely need to focus on more personal software.
This software is very unpolished and only targeted for my personal use. That said, if you want to look at it (or even give me some advice) you can see it here