Airblader

Just now saw this comment. That's really neat, pleasure to "meet" you. :-) That naming certainly gave me some headache over the years because it always stuck, and seems to be the cause of all the heated discussions. Anyway, I also wouldn't have it any other way now!

The PR is coming from one of the core maintainers, so yes, it will be accepted.

It doesn't just implement this specific feature, though. It provides a more general approach for i3bar that enables this and many other use cases. This struck us as a good and flexible solution we can get behind.

I can promise you that in a decade of doing this, I've made my fair share of mistakes as a maintainer. There's a learning curve to everything, and maintainer burnout is a real thing, too.

i3 should definitely work on BSD, there are a few awesome folk that regularly send patches when we broke something. I don't have experience with it myself though.

I think the in-person meeting made this a bit easier, but we had been talking about it prior to that, so I think it would've happened either way.

Not supporting vertical dock clients is indeed a limitation in i3, using another dock client doesn't help here.

There's an open PR that will make this possible.

The footnote is that I didn't author the idea of gaps in i3. There used to be a loose patch floating around that applied to an old version of i3.

When I came to Linux I quickly got into the unixporn community. After a bit of making Ubuntu look nice, I discovered i3. I then found the gaps patch and rebased it onto the latest version of i3 at the time. Lots of unixporn people liked that and asked me to create a repository for it, so I did -- and i3-gaps was born.

The reason I say it's true enough to say it was born on unixporn is that it's where "a gaps patch" turned into "i3-gaps", and also I reworked so much of that initial small patch that it became something new essentially.

I think that's an unfair and fundamentally false representation of the discussion on that issue. But I won't further comment on it here.

The pleasure has been all mine. :-)

I see your point (in general terms). But I think people tend to overlook the hidden costs of optional features in terms of maintenance and complexity (in code, documentation, and for users).

In i3 we have always tried to weigh benefit against cost. We also really care about compatibility. It's easy to add a feature, difficult to maintain it, and impossible to remove it.

This will make some people sad, but I'm on Mac these days.

I was using i3 until the very end though, and I do dearly miss proper window management. My shortcut setup now is an absolute mess. I technically did run i3-gaps because of some features, but not gaps. This was mostly because I actually mostly used a one window per workspace approach, and if more, then a tabbed layout, so no need for gaps there.

/r/unixporn is where i3-gaps was born, as a matter of fact.

There's a small footnote to this, but I think it's true enough to say it like that.

Back when I used i3-gaps myself (yes, that time is behind me, sorry), I liked the visual clarity gaps provide. And from years of interacting with the community I know many people feel the same way. It just makes things feel less cluttered.

Hi. I'm the maintainer of i3-gaps and also a maintainer for i3.

The story of this merge is not only several years long, but a true success story in OSS in my eyes.

I took on i3-gaps by taking an existing patch and rebasing it to the latest i3 HEAD. From there it became popular and I took on the maintainership, eventually contributing to i3 itself and finally becoming a maintainer there as well.

Whilst originally gaps were considered an "anti feature" for i3, years ago we already decided that we'd accept adding gaps into i3. Clearly the fork was popular, and as someone else pointed out here as well, the Wayland "port" of i3, sway, added gaps from the beginning on with great success.

However, the original gaps patch was focused on being small and easy to maintain. It caused a few issues and had some drawbacks. We made it a condition that porting gaps into i3 would have to resolve these issues. Alas, this could've meant a lot of work that no one took on for the years to follow.

Recently, however, the maintainers of i3 got together (a chance to meet arose randomly). During that meeting we decided that it'd be better to just merge the fork and improve it later. And as it happened, Michael, the author and main maintainer of i3, did all that work during the port as well.

What resulted is the end of almost a decade of i3-gaps, and a much better implementation thereof. I'm incredibly happy to see this happen after all this time, and a big shoutout to Michael here for all that work.

Edit: Hadn't realized Michael was commenting here already. I guess leaving the background and story from my side of things doesn't hurt regardless.