Ivan MolodetskikhPhew, finished the initial implementation of window screencasting in niri! Complete with stream resolution change on window resizing.
Some details are still iffy regarding frame timing and frame callbacks, especially to obscured windows, but it *should* work decently fine for now.
niri v0.1.7 is out with fractional scaling, window screencasts and many smaller improvements!
Oops, looks like niri had outstarred PaperWM on GitHub ๐
PaperWM introduced me to (and made me fall in love with) scrollable tiling. It's a solid implementation on top of GNOME, so you get all the benefits of running a stable and well-supported DE (and Xwayland). PaperWM is also a very direct inspiration for many parts of niri!
Implemented the thing where you can toggle the mouse pointer on the screenshot after the fact (by pressing P). Gonna add a help panel here soon to remind you of this.
Much better
key repeat + scrollable tiling = fun
One of the niri users has contributed a gradient interpolation color space setting! Now you can do pretty gradient borders in srgb-linear, oklab and oklch (in all four hue directions).
I made a COPR for git builds of niri: https://copr.fedorainfracloud.org/coprs/yalter/niri-git
Apparently this is a thing you can do; relatively easily, even. It's fully automatic, triggers on a webhook from GitHub.
Thanks Michael (my4ng) from our Matrix channel for showing me the relevant docs and doing the initial work!
Spent a better part of today, but I've got dmabuf modifier negotiation fully working in my pipewire screencasting code in niri! This happens to finally fix screencasting on NVIDIA GPUs. Still haven't got any GStreamer pipeline working though, maybe needs a pipewire update.
Apparently, my AMD selects a BGRA format modifier that has two planes. Some out of band info I suppose. And on Intel a preferred BGRA modifier has three entire planes!
My Wayland compositor, niri, turns one today! 
Here's v0.1.8 with bind key repeat, screenshot UI pointer toggle, gradient color spaces, wlr screencopy v3 and output management, and lots of other improvements: https://github.com/YaLTeR/niri/releases/tag/v0.1.8
omg, my friend drew a birthday nirik 
i recorded a demo video for the focus-follows-mouse section to showcase it lol
Several days and a lot of hair pulling later, I *think* I got resize transactions working?? Maybe? Hopefully?
Resize transactions is when all windows that must resize together, resize together, with no mismatching frames in between. For example, all windows in a column must add up to the full screen height.
This requires correct configure acks on the client (looking at you, Blender) and very careful state update delaying and resize throttling on the compositor side.
narrator: there was still one case where it didn't work due to a bug
okay, surely this time it definitely works for all correctly written clients
Here's one mainly for people who disable animations: window closing now runs in a transaction with the other windows resizing. This means, no background flicker.
There's been another logo discussion in the niri Matrix room with some quite interesting concepts emerging. Here's one by Endg4me_ with edits by bluelinden and myself, and inspiration from a concept by ElKowar.
What do you think?
I'm working on an "event stream" IPC for niri where you get notified about events as they happen. For example, "workspace switched" or "keyboard layout changed".
To give it a good test, I actually started implementing native niri support in Waybar. You can give it a try too: https://github.com/YaLTeR/niri/pull/453#issuecomment-2317110904
I finished the initial event stream IPC implementation for niri. My Waybar fork implements a decent amount of the modules niri/workspaces, niri/window, niri/language. Please give that a try, also anyone who makes IPC scripts or bars please give a try to the event stream IPC itself so we can find any design flaws before merging.
The PR you will need: https://github.com/YaLTeR/niri/pull/453#issuecomment-2321730996
Waybar fork is linked from there.
The other day, Christian Meissl finished updating and publishing the libdisplay-info bindings [1]. This is quite exciting because, unlike edid-rs, it can parse the manufacturer/model/serial from pretty much any monitor.
So, today I spend a few hours integrating the manufacturer/model/serial monitor addressing all throughout niri: config, IPC, niri msg, screencast output selector. You should now be able to write/use "SomeCompany CoolMonitor 1234" everywhere!
Set up CI rustdoc publishing for niri-ipc: https://yalter.github.io/niri/niri_ipc/
This has the entirety of the niri IPC documented, including the new event stream events.
After the Waybar maintainer speedran merging my niri modules and releasing, I would feel bad delaying any longer, so here's niri 0.1.9 :)
Event stream IPC for bars, better window resizing, properly named outputs, on-demand VRR, out-of-the-box fix for NVIDIA flickering, and other improvements!
Over the past 2 weeks I've been slowly but surely working on the interactive move niri PR [1] by @pajn. It's already got me to fix quite a bit of tech debt in the layout code, which is cool.
The PR is still rough around the edges, but mostly works, and I switched to running the branch on my own systems to give it thorough testing.
(also no, this is not the Floating Layer yet, though it's a good step towards that)
Attaching a video of what it looks like rn
Made interactive move work on touch (and resize too while I was at it), didn't need that many changes actually
Added a bit of rubberbanding before the window is "dragged out" of the layout. Should help avoid unintended layout changes.
Along with a few more fixes I did, I think interactive move should be good to merge? It's not 100% perfect and jank free, but I'm fairly sure I got all the important things done. Will give it some more testing.
Suddenly, @drakulix showcasing the Cosmic session running on, among other compositors, niri! On the big screen at the Ubuntu Summit ๐
somehow this touch moving under stationary pointer works better than i expected
(yes trying to do a precise left click with an elbow was difficult)
By the way! I'll be giving a talk at RustCon in Moscow on December, 6! 
Wherein I will briefly describe what a Wayland compositor is, and then show several testing and profiling workflows that I've been using to keep niri stable, robust and performant.
(The invitation to submit a talk was completely unexpected, guess niri found its way into the right eyes. ๐ )
There will be a recording, though in Russian.
Interactive window moving, laptop lid and tablet mode switch binds, mouse and touchpad scroll speed setting in today's niri v0.1.10 release!
https://github.com/YaLTeR/niri/releases/tag/v0.1.10
Also, niri-ipc is now on crates.io, but keep in mind that it will not be Rust-semver-stable: https://crates.io/crates/niri-ipc
Added scaffolding for layer rules, along with a block-out-from rule. Now you can finally block notifications from screencasts!
Though, layer-shell surfaces don't have a "geometry" so if they have shadows or transparent padding, all of that becomes solid black, since niri has no way to know where the "actual content" of the layer surface is (that's what geometry is for windows).
Thanks to Christian Meissl's fix in Smithay, the git version of niri correctly shows nested pop-up menus in lxqt-panel. They also submitted a fix for invalid pop-up spawning to ironbar, which makes it work on Smithay compositors.
Today I merged a PR by FluxTape which adds "always empty workspace before first" to niri. At the surface this is just a simple config flag with obvious behavior, but it's actually full of edge cases! Things like which workspace to focus at startup. The code refers to workspaces by index in many places, and those all shift when you suddenly insert an empty workspace at index 0.
Took several days to catch them all even with our randomized tests, but I think it should be good now.
>while testing, already found two uncaught regressions introduced in previous niri releases, and no issues with the refactor
This morning was my niri (-adjacent) talk! 
Went really well, got many interesting questions!
They promised us video recordings in a few days, so I'll post a link when I get it. Though of course the talk is in Russian.
I'm thinking of switching niri to the year.month versioning. So instead of 0.1.11, the next release will be 24.12 or 25.01, and so on. Hotfix releases will use patch like 25.01.1.
Are there any issues with this versioning that I should consider? There won't be releases more frequently than monthly so that's not a problem.
Julian Hofer
algernon fought nix, and won (for some values of won, nix, fought, and algernon)
sodiboo 
may I suggest using a four-digit year like Sharkey does? this way, it's "obviously" date-based even with no context or explanation. in particular, they have
yyyy.m.n where n=1 at the start of each month and increments after each release. which is basically equivalent to what you were thinking of except it always specifies a patch number, even if only one release happens in a month
@sodiboo hmm. Admittedly, it took me an embarrassingly long time to realize that the year.month in Ubuntu is, in fact, year.month, and four digits would clear that up a bit. I would prefer zero-padded double-digit month for the same reason.
On the other hand, spelling out the whole 2024 seems a tad redundant, and there are other projects like Helix that use double-digit year.month so it's not like there's no precedent.
(even if redundant I do think it's more aesthetically pleasing, and it's not like the length has any practical downside?)it took me an embarrassingly long time to realize that the year.month in Ubuntu is, in fact, year.month, and four digits would clear that up a bit. honestly yeah same, but now that I am aware of this and I've seen it in several other distros, that scheme reads to me as usually-semiannual. and given that niri is a compositor which is such a core component of a system that it's not uncommon to align with distro releases, it would make sense just by the class of software for niri to have such s release schedule.
this is, additionally, the only argument I can think of against
YY.MM. like it's all arbitrary anyways and it doesn't really matter in the end because you do have to pick something, but personally I like four-digit year betterI would prefer zero-padded double-digit month [because it's more obviously rooted in the Georgian calendar] yeah I have no opinion in favor of or against this.---
also worth considering: at a certain point, a patch release might look like it's the full date. like when I installed Sharkey, I assumed
2024.5.3 meant it's from the third of May (it means that's the third release in May). so maybe a different separator is worth using, to show that the third field isn't a date? I guess it's "obviously" +.> ok but what if niri lives to be 100 years old? wouldn't want another Y2.1K now would we?
The world runs on huge AI clusters. Everyone is streaming their thoughts into a neutral network and receiving the complete rendered output directly into their brains. And then there are the two weird users, one connecting to the singularity through an IRC bridge, and the other scrolling tiles on their ancient manual computer
so you should probably make the year 4 digit to prevent this apocalypse scenario.
Tau ๐ณ๏ธโ๐
chfkch 
unusual sights
Turns out, there's a lot of details to get right when implementing a floating window space. For example, dialog windows should always show above their parent window. Otherwise, it's easy to lose them under the (usually much bigger) parent.
The WIP floating branch in niri now handles this properly, even for xdg-desktop-portal dialogs (like file chooser) as long as the app correctly parents them via xdg-foreign.
Another piece of the floating puzzle: keeping windows on screen. When you change your monitor scale or resolution, you don't want your floating windows to suddenly go unreachable behind the monitor's new borders.
Here I'm resizing a nested niri with three windows, simulating resolution changes. No matter what I do, they always remain partially visible and reachable. Even for more unusual cases like trying to resize a window into out of bounds.
In the tiling layout, niri is constantly asking windows to assume their expected size. In contrast, floating windows should be able to freely change size as they see fit.
The logic turns out to be quite tricky. On the one hand we want a window to keep its latest size, but on the other we still want to be able to resize the window, which means asking it for a different size. The window can take a second to respond, or respond with a yet another size, and nothing must break.
While trying to make this work, I realized that this is the time when I *really really* want to be able to test this stuff. So I got on a sidetrack adventure to write testing infra for running real Wayland clients inside unit tests.
I've got it working! In these tests, I'm creating a new niri instance along with test clients, all on the same test-local event loop. No global state, no threads needed.
What's really cool is that this lets me test the weirdest client-server event timings.
This morning I worked on remembering the size for floating windows when they go to the tiling layout and back.
The whole sizing code must be at the top by logic complexity in niri. I have to juggle, all at once:
- new size I haven't sent to the window yet,
- size changes I sent, but window hasn't acked yet (0, 1, or more in-flight),
- size change window acked but hasn't committed for yet,
- size change window acked and responded to with a commit (maybe with a different size entirely).
The diff is 85 lines of change and 243 lines of new tests, and I already found a few weirder edge cases that I've missed. No way I could do this well without that client-server testing setup that I posted about yesterday.
Btw I pushed the testing setup if you're curious, along with the entirety of 1215 snapshot files for a powerset of new window workspace/output target settings: https://github.com/YaLTeR/niri/commit/771ea1e81557ffe7af9cbdbec161601575b64d81
The WIP floating branch caused them to update in several commits already.
The big 1215 snapshot test powerset (actually it already grew to 1695) continues to prove its worth. Just finished a big +495 -508 cleanup of the window opening code, and verified that not a single of those 1215 window opening configurations changed its outcome. I will be sleeping well tonight
After three weeks of hard work, I am undrafting the floating window PR in niri. Please give it thorough testing and report any bugs or issues!
Psyhackological
But will try Gnome's too.
armerpunkt
ralen@chfkch yeah it's a bit weird; I left a comment about it in a different test.
What I suspect is happening is that since niri sends its configures at the very end of its event loop iteration, it frequently happens that the client receives and processes the roundtrip response right before that configure.
For some reason it happens quite frequently with many threads. I'm not sure what's thread dependent, but two roundtrips should guarantee against this particular problem at least.
Eduardo Flores 
drusk
ElKowar
TheZoq2
Paranoid
Sasaigo
huilong 
phisch
Jons Mostovojs
Alexander Sosedkin 
Sergey Bugaev
ฯ
Areskul
David Runge
karthik
scientiac
VBBโ๏ธ
lucie lukas "minute" hartmann
Ryan Brue
David 
olivia, 
โ
LXQt-Project
Tobias Bernard