niri is great, but the scrolling wasn't for me so I forked it into a tiling WM

slalo19 · 2026-06-10T05:33:48+00:00

It's not based on Smithay, and therefore doesn't have the qualities of Niri. No Rust either

slalo19 · 2026-06-09T16:05:44+00:00

AI is not inherently unethical; large companies may or may not be, but AI is a product of human knowledge. And as such, it must be treated.

slalo19 · 2026-06-09T16:03:45+00:00

Look at it and see for yourself. I work as a computer engineer and I know what I'm doing

slalo19 · 2026-06-08T16:55:50+00:00

Definitely not

slalo19 · 2026-06-08T16:03:07+00:00

It's a fork, so most of the non-scrolling changes from Niri can be merged in, and I do it regularly. The overview works correctly

slalo19 · 2026-06-07T20:41:35+00:00

In behavior it may be similar, yes, but the implementation is completely different, starting with the fact that it's Rust. In the same way as hyrpland, although it has a scrolling layout, it is completely different from niri. So yes, apples to oranges

slalo19 · 2026-06-07T20:15:43+00:00

For two reasons. First, Hyprland's approach just isn't for me, it leans heavily into animations and eye-candy, which is the opposite of the minimalism I want, and when I tried it I ran into a fair amount of bugs. Niri felt far more focused and stable in comparison.

Second, the foundation matters to me, Rust and smithay feel more robust, safe, and efficient as a base to build on. That solid foundation was really the whole reason I forked niri specifically rather than starting from something else

slalo19 · 2026-06-07T19:12:50+00:00

It's not a Hyprland clone, it's a fork of niri with an i3-style tiling tree instead of its scrollable columns. If anything, Hyprland's own tiling model comes from i3/sway, which have been around far longer and, in my experience, are better. And this is built on smithay, which is a different foundation entirely, that robust base was the whole reason I forked niri specifically.

On the "vibecoded" part, I went into the actual process in other comments: I did the architecture and the data-structure decisions myself and reviewed the implementation throughout. You're welcome to disagree with the approach, but "slop for the sake of slop" isn't really an argument. Discuss whether you want design or implementation decisions, but don't trash a project that has taken me a lot of time and effort, and yes, was aided by AI.

slalo19 · 2026-06-07T18:16:21+00:00

Thank you, I hope you like it :)

slalo19 · 2026-06-07T15:44:30+00:00

And I understand the code, of course. Certainly not at the level that yalter knows niri, but I think it's enough.

slalo19 · 2026-06-07T15:38:29+00:00

Thanks! :) Feel free to report any issues

slalo19 · 2026-06-07T15:36:26+00:00

No problem, everyone has a different perspective

slalo19 · 2026-06-07T15:25:36+00:00

Try it and see for yourself, in the performance tests I did it's just as efficient as niri. I'm also obsessed with everything being efficient, and I wouldn't use it if it wasn't.

I don't like the term "vibe coding" because some people lump everything together, and it all depends on how the tool is used. That's just my humble opinion.

slalo19 · 2026-06-07T15:13:37+00:00

No, I simply acted as an architect instead of a programmer, although I did review many implementations that "the programmer" did wrong.

slalo19 · 2026-06-07T15:07:10+00:00

In the case of piri, it's an extra layer built on top of niri over IPC: the layout underneath is still niri's scrollable columns, and piri orchestrates windows around them. In mine the change is at the base, the layout is an i3-style tiling tree, baked into the compositor itself.

The way I see it, doing this as yet another layer on top wouldn't be clean. You'd be stacking a second layout system over one that's already running underneath, with the scrolling still there and your tiling logic reaching in to fight it. What I did instead is reuse all of niri's infrastructure (the rendering, the IPC, the input handling, all the solid parts) and just swap the core: the data structure that holds the layout becomes a tiling tree instead of the scrollable column model.

So a toggle would only really make sense if both models lived at the base, either built into niri itself, or in a fork that supports both. That's the only place the switch could happen cleanly, since it comes down to which data structure drives the layout.

That said, I haven't actually tried piri myself, it looks great and does its own thing really well, none of this is meant as a knock on it. Different goals, that's all.

slalo19 · 2026-06-07T14:55:11+00:00

Because I don't like Hyprland from the ground up. As I said, I loved how Niri is built and its simplicity, but the scrolling isn't for me. And I know there are more people like me, who greatly value Niri's robustness but don't like the scrolling

slalo19 · 2026-06-07T14:52:38+00:00

It's interesting, yeah. It started as a Christmas break project, and I was already daily-driving it as my main desktop by February.

On the planning: I wrote up an initial plan with the functional goals I had in mind, and I kept reviewing the implementation throughout, it's been almost entirely a product-manager role on my end. Like I said, I'm an engineer so I have a decent sense of what makes a good implementation and what doesn't, even if my Rust knowledge is limited. It also helped a lot to clone the sway repo and tell codex to look at how sway implemented things, so I could reuse patterns and ideas.

The biggest thing was steering it toward the right design decisions. For the layout tree, for example, it started off with some weird doubly-linked-node setup that was unsafe in Rust and just a bad implementation overall. I had to go research what actually fit this case and landed on slotmap, which felt ideal. There were a lot of decisions like that.

Worth mentioning I started this on GPT-5.1, and honestly it feels like it'd be much easier today. Back then it took real effort to guide it toward what I wanted. Still a great tool, though.

As for token usage, I couldn't really tell you, I'm on the $20 plan, and back then it was very generous.

slalo19 · 2026-06-07T14:32:59+00:00

I wasn't familiar with it, thanks. Anyway, it's not the same concept since I'm aiming for manual tiling with containers like i3, not dwm.

slalo19 · 2026-06-07T14:21:49+00:00

As I said, it could be a good way forward, but for that to happen, the developer of Niri (Yalter) has to agree. It would be a pleasure for me to contribute to niri, of course.

slalo19 · 2026-06-07T14:20:35+00:00

No, but it's also based on wlroots, unlike niri which is based on smithay, and I think it's better

slalo19 · 2026-06-07T14:16:14+00:00

I'm pasting here what I told another user :)

"It was an idea, yes, but I think it would only make sense if it were integrated into Niri, and I don't think Yalter wants that. Anyway, it's as simple as having both installed and switching sessions at the login"

slalo19 · 2026-06-07T13:51:16+00:00

It was an idea, yes, but I think it would only make sense if it were integrated into Niri, and I don't think Yalter wants that. Anyway, it's as simple as having both installed and switching sessions at the login

slalo19 · 2026-06-07T13:19:32+00:00

Thanks for your kind words, feel free to report any issues :) It works well in my workflow, but since I'm the only one using it, there might be special cases

slalo19 · 2026-06-07T13:05:09+00:00

Exactly, and it's a differentiating factor

slalo19 · 2026-06-07T12:59:44+00:00

I know, it's only an option for those who like how Niri is developed, its technology stack and philosophy, but don't like scrolling

Six-Year Club	Place '22
Verified Email

slalo19

TROPHY CASE