mastodon.online is one of the many independent Mastodon servers you can use to participate in the fediverse.
A newer server operated by the Mastodon gGmbH non-profit

Server stats:

12K
active users

omg, my friend drew a birthday nirik :blobcataww:

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: github.com/YaLTeR/niri/pull/45

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: github.com/YaLTeR/niri/pull/45

Waybar fork is linked from there.

Some basic scaffolding for an event stream IPC.


Changed the client to read only a single line worth of response.
This mirrors how the server works, and will be necessary to tell apart further mes...
GitHubEvent stream IPC by YaLTeR · Pull Request #453 · YaLTeR/niriBy YaLTeR

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!

[1]: lib.rs/crates/libdisplay-info

Set up CI rustdoc publishing for niri-ipc: yalter.github.io/niri/niri_ipc/

This has the entirety of the niri IPC documented, including the new event stream events.

yalter.github.ioniri_ipc - RustTypes for communicating with niri via IPC.

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!

github.com/YaLTeR/niri/release

wtf did I Just Make

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

[1]: github.com/YaLTeR/niri/pull/547

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 😄

github.com/Drakulix/cosmic-ext

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! :ablobcatwave:

rustcon.ru/

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.

rustcon.ruRustConКонференция по языку программирования Rust, Москва, 6 декабря 2024

Interactive window moving, laptop lid and tablet mode switch binds, mouse and touchpad scroll speed setting in today's niri v0.1.10 release!

github.com/YaLTeR/niri/release

Also, niri-ipc is now on crates.io, but keep in mind that it will not be Rust-semver-stable: 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).

We hit 4000 stars today on the niri repo!! :ablobcatheartsqueeze:

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.

Somehow, a small change for tests escalated into trying to completely refactor how animation timing works in niri. And right now I find myself at the exact opposite of this picture. Unfortunately, time has not stopped and is causing problems

Like three complete refactors later, I think it's... working? For real this time? No weird issue is gonna sneak up that undermines the whole design?

Nothing seems to have caught on fire after one more day of personal testing and one more day in main. So here's a technical page I wrote about the the new niri animation timing design and its motivations: github.com/YaLTeR/niri/wiki/An

A scrollable-tiling Wayland compositor. Contribute to YaLTeR/niri development by creating an account on GitHub.
GitHubAnimation TimingA scrollable-tiling Wayland compositor. Contribute to YaLTeR/niri development by creating an account on GitHub.

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.

>did a +4,657 −4,237 refactor in the layout code
>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! :ablobcatbongo: 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.

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: github.com/YaLTeR/niri/commit/

The WIP floating branch caused them to update in several commits already.

These tests make a real Niri instance and real Wayland clients (via manual
wayland-rs implementation), both on the same event loop local to the test. This
allows testing the full Wayland interactio...
GitHubImplement client-server test infra and window opening tests · YaLTeR/niri@771ea1eThese tests make a real Niri instance and real Wayland clients (via manual wayland-rs implementation), both on the same event loop local to the test. This allows testing the full Wayland interactio...

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!

github.com/YaLTeR/niri/pull/871

Early happy new year! 🎉

Thanks to everyone who helped with testing and ideas!

I spent today figuring out the remaining layer-shell keyboard focus problems, and I've got it all working! Pop-ups now render above windows, and bottom/background layers can receive on-demand focus.

Effectively, this makes the desktop icons components from @LXQt or @xfce just work on niri!

Alright, I think I got all of the important things in for the next niri release. Today I updated Smithay for the DRM compositor changes, and added a workaround for a panic when you have two monitors with exactly matching make/model/serial.

I'll give it a week of testing (if you run niri-git, please report any problems) and if all goes well, tag next Saturday.

There are a few PRs I'll try to review in time, but they're fairly self contained.

Ivan Molodetskikh

After a full day of writing release notes (god how'd it take so long 😫), niri v25.01 is out with Floating Windows and Working Layer-Shell Desktop Icons and Layer-Shell Screencast Blocking Out and so many more improvements! Yes, you read that right, we finally escaped zerover! I feel that niri is now ready to graduate from v0.1 :ablobcatbongo:

Read here and download when your distribution package updates: github.com/YaLTeR/niri/release

i was finishing writing these to celeste reach for the summit ost lol

something odd about these windows

this is a completely normal screenshot. nothing unusual here

Looking for testing and feedback for server-side shadows: github.com/YaLTeR/niri/pull/990

ppl from our niri matrix playing around with the new compositor-side shadows! These screenshots are from @r4hulrosh4n and calops (no fedi)

Added shadow support for layer-shell surfaces!

Though unfortunately layer-shell has no way to signal the visual geometry, so this only looks right if the layer surface doesn't have its own margins.

github.com/YaLTeR/niri/wiki/Co

I'm adding tabs to niri. Instead of some separate mode, they're just changing how a column is displayed. This means all your hotkeys and everything works exactly the same with tabs. Which was a wonderful UX idea by @elkowar!

I've got a draft PR going with some design and UX questions, please feel free to try it and give feedback: github.com/YaLTeR/niri/pull/10

Why would you even want tabs in niri? Occasionally it's quite useful. For example, when streaming programming, I increase the font size, so I can no longer fit editor + terminal on the screen at once. Scrolling back and forth gets annoying, and tabs feel just right for this.

We just hit 5000 stars! 🎉

A ton of changes in the tabs PR over the past few days. Mainly various options (tabbed display by default, tab indicator position, etc.).

Just finished with a big one: you can now place the tab indicator within the column rather than "outside". This is needed for thicker tab bars, since otherwise they overlap adjacent windows.

github.com/YaLTeR/niri/pull/10

I merged tabbed columns into niri! Now you can play around with them using your nearest niri-git package. With working animations and all :ablobcatbongo:

Noticed tabs can sometimes be useful for comparing windows without taking screenshots. Here for example I'm running the Adw demo from F41 vs. nightly Flathub, showing the slight color difference and apparently a 1 px layout shift.

Another cool suggestion by @elkowar: you can now match windows recorded by an active window screencast. For example, to highlight the casted window with a different color.

Today in *very long* overdue features (looks like I opened the issue even before v0.1.0): moving the mouse against a monitor edge now scrolls the view during drag-and-drop.

(before this change, you had to use the keyboard for this, and yes it was very awkward)

Another neat new thing: a bind to expand column to available width. Basically, "expand to fill empty space".

But, a bit smarter: with scrollable tiling we can have windows partially off-screen. This bind ignores such windows, making it easy to position things to exactly fill the screen, even in the middle of a scrolling layout.

@YaLTeR Hell yea, congrats!!

I feel like celebrating leaving zeroVer, when your solution is just fully moving to calver, is... funky lmao

@elkowar for this one I definitely waited to change the version until I felt that it was ready to leave v0.1. Maybe if not for calver I would've called this a v1.0

@YaLTeR Where did you get that background? I love it!

@dperson good question. Last year I went through some wallpapers subreddits, must've been from there somewhere

@YaLTeR "two lines of fastfetch". Old neofetch is already forgotten

@YaLTeR Do the shadows provide the same shape regardless of the window's shape? i.e. more or less roundness in the corners

@ryanabx they use the same thing as border and focus ring, which is unfortunately simply a window rule for geometry corner radius. If you don't window rule it, it will assume that the window has square corners. And if you do set a corner radius with the window rule, the shadow will also use the correct corner radius.

A Wayland protocol for toplevels to tell what their CSD corner radius is would be real nice here

@YaLTeR yep, on the cosmic side we've had the same want!

@YaLTeR hi Ivan, can I install niri on fedora in some default configuration with recommended plugins, ready to use? I would like to test it on the same pc I have gnome installed, but don't want to configure it.

@VBB hey, you can use my COPR: copr.fedorainfracloud.org/copr

That'll give you a few utilities like fuzzel (app launcher) and swaylock (screen locker), but no bar and no xwayland-satellite. So you'll still need to do some configuring for a comfortable session (though, everything else will work out of the box, including portals, etc.).

There are some COPRs for xwayland-satellite, haven't tried them: copr.fedorainfracloud.org/copr

copr.fedorainfracloud.orgyalter/niri Copr

@YaLTeR hii kinda unrelated but do u know of anyone who made a script for a dmenu window picker in niri ? i wanna make one but i wont if theres one already floating around haha , i just couldnt find it

@fiore yeah ppl did make, search in Discussions. I don't have link handy

@YaLTeR oh okie thank u very much ill look more ^^

@YaLTeR only thing I can see is a man using the right vcs.

@YaLTeR slightly related: what do you use for screen recording?

@YaLTeR i was afraid you'd say that 🙈

Oh well there must be some things left where's GNOME still better 😋

@ju it's certainly a bit annoying for area recording, but aside from that it's very robust

I am regularly trying to get Kooha to work, but there seems to be some problem in gstreamer-pipewire where it doesn't want to connect with my DMABUF-only screencasting

@YaLTeR yeah, i wasn't able to get kooha to work at all unfortunately

@ju @YaLTeR I hope you're aware we have @YaLTeR to thank for the one in GNOME ;)

@jimmac @YaLTeR i always forget which one Ivan made. I thought screenshot was Ivan, and screencast was Jonas?

@YaLTeR @elkowar they look awesome! Does it implement window rules for auto-merging windows in the same column? This would suffice the need for window swallowing and be pretty useful for some apps.

@arthsmn no rules for auto-merging (how would this work?), you just have a bind to toggle a column between normal and tabbed mode

@YaLTeR like, given a window, all windows (or certain windows, could be regex-based) opened by this one enables tabbed mode and join them together. Eg. opening mpv from a terminal puts them in the same column in tabbed mode. This can also not be tied to the relation between windows, depending only on the focused window having this rule and then other windows matching regex would enable this feature.

@arthsmn

> opened by this one

so yeah, this is the main problem here. There's no way to track this generally. Especially in terminals which don't (yet?) send xdg-activation tokens to processes they spawn

@YaLTeR so the regex approach on the focused window would be the only feasible approach? I think this can be scripted, might try it another time.

@YaLTeR @arthsmn back in my old XMonad days I wrote a window swallowing module that looked at the NET_WM_PID (or whatever its called) of windows, and if a new window opened that was the child process of another window, I detected that and did the window swallowing stuff. Very very janky, but it mostly worked. No idea how viable that is on Wayland, and no idea if it's that great of an idea though.

@YaLTeR @arthsmn i think this is great and would very likely be a great subsitute for swallowing , while also allowing the user to still check the terminal window in case of need !! great all around ^^