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

#wayland #smithay #rust #niri

Release v0.1.10 · YaLTeR/niri

Niri is a scrollable-tiling Wayland compositor. Windows are arranged in columns on an infinite strip going to the right. Opening a new window never causes existing windows to resize. Here are the i...

GitHub

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).

#niri

We hit 4000 stars today on the niri repo!!  

#niri

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.

#niri #lxqt

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: https://github.com/YaLTeR/niri/wiki/Animation-Timing
Animation Timing

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

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.

#niri

>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!  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.

unusual sights

#niri

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.

#niri

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.

#niri

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.

#niri

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.

#niri

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).

#niri

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.

#niri

Implement client-server test infra and window opening tests · YaLTeR/niri@771ea1e

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...

GitHub

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

#niri

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!

https://github.com/YaLTeR/niri/pull/871

#niri

Floating windows by YaLTeR · Pull Request #871 · YaLTeR/niri

So fed up with scrolling tiles. I'm converting niri into a floating WM. Just kidding. This is a floating window layout on top of the scrollable-tiling layout. The floating layout does not scro...

GitHub

Early happy new year! 🎉

Thanks to everyone who helped with testing and ideas!

#niri

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!

#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.

#niri

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  

Read here and download when your distribution package updates: https://github.com/YaLTeR/niri/releases/tag/v25.01

#niri #smithay #wayland #rust

Release v25.01 · YaLTeR/niri

Niri is a scrollable-tiling Wayland compositor. Windows are arranged in columns on an infinite strip going to the right. Opening a new window never causes existing windows to resize. Here are the i...

GitHub

something odd about these windows

#niri

this is a completely normal screenshot. nothing unusual here

#niri

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

#niri

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

#niri

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.

https://github.com/YaLTeR/niri/wiki/Configuration:-Layer-Rules#shadow

#niri

Configuration: Layer Rules

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

GitHub

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

#niri

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! 🎉

#niri

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.

https://github.com/YaLTeR/niri/pull/1085

#niri

Tabbed columns by YaLTeR · Pull Request #1085 · YaLTeR/niri

Tabbed display mode for columns. Implements #933 / #876. This is a WIP draft meant to gather feedback and figure out how exactly this should work. I know animations are broken, I'll deal with ...

GitHub

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

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.

#niri

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.

#niri

Configuration: Key Bindings

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

GitHub

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)

#niri

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.

#niri

Today I'm releasing niri v25.02 with tabs, shadows, DnD view scrolling, and a ton of other improvements! Read the release notes at https://github.com/YaLTeR/niri/releases/tag/v25.02 and @ your distro to update the package.  

[[honestly wtf how did so much stuff happen, it's been barely over a month]]

#niri #smithay #wayland #rust

@YaLTeR lmao, the meme on the left
×

After trying a few approaches, I ended up doing it "properly" by associating the (entirely compositor-side) windowed fullscreen state to window configures and commits. This lets niri correctly track if a given fullscreen window commit was real fullscreen (so e.g. we need to draw a black backdrop), or if it was windowed fullscreen.

This even works across a chain of toggling windowed fullscreen, then the window slowly acking and committing them, and I have a test to verify that.

#niri

New niri users frequently come from other tiling WMs with static workspace systems. For them, dynamic workspaces is an unusual system, and it can be unclear how to use dynamic workspaces effectively. (Especially until we get an Overview type thing.)

I figured I'd write a wiki page describing niri's workspaces in more detail: https://github.com/YaLTeR/niri/wiki/Workspaces I also included an example of how I personally use workspaces on niri.

Hopefully this makes it easier to understand what's going on!

#niri

Workspaces

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

GitHub

slowly going through the piled up PRs (how's your weekend going?), today merged the pick-color IPC from nnyyxxxx. comes with Portal support of course

#niri

A secret niri v25.02 feature! Make your floating windows FLOAT by putting this in your config:

window-rule {
match is-floating=true
baba-is-float true
}

Works in the nix flake too  

#niri #wayland

started working on an Overview for niri. very wip, lots to do, got some basic rendering and dragging working though

#niri

today's progress: wheel scrolling up and down, right click to scroll left and right, click on workspace to focus, some keyboard fixes

this is all mouse-only on the video. only currently using a 3rd-party tool for the hot corner (waycorner), i'll integrate that later

#niri

i have this old ASUS Eee PC collecting dust, decided to try if niri will run on it. well, it actually runs! a few shaders failed compiling (ran into ALU instruction limits), but otherwise seems to work

#niri

also reproducing the "unable to screenshot on old intel driver" issue on this: https://github.com/YaLTeR/niri/issues/807
Not Screenshots · Issue #807 · YaLTeR/niri

System Information niri version: 0.1.10.1-1 Distro: ArchLinux GPU: Intel Mobile 4 Series Chipset Integrated G] CPU: Intel(R) Celeron(R) 900 @ 2.19 GHz Screenshots are not created at all! When you t...

GitHub
i think i'll throw sway atomic on this and layer niri. so that it can collect dust in a more useful fashion
apparently sway atomic is really barebones with barely anything installed, also whatever the default display manager is, fails to render any text. I'll try to rebase to silverblue ig?
@YaLTeR I always wondered if the atomic paradigm and the window manager paradigm were a particularly good fit.
@jdw the two are completely orthogonal
@YaLTeR that's odd, my (crappy) niri image is based on Sericea/Sway atomic 🙃

today's overview progress: some rendering and input fixes, plus implemented built-in hot corner, and workspace switch on drag-and-drop hold. which means that now you can perform an entire drag-and-drop to a different workspace mouse-only!

#niri

spent many hours today trying to make the combined exit overview + switch workspace animation monotonic. This is hard because zoom and vertical movement are separate axes, and you can e.g. "catch" one of them with a touchpad gesture, while the other must continue animating (so you can't easily convert this into rect interpolation).

Ended up working out a correction formula for the workspace Y positions when both axes have matching animations. Appears to behave so far from my testing

#niri

you know it's bad when you need to write a big comment with formulas and derivations

today I opened a draft PR for the Overview, and request everyone to test it and report issues: https://github.com/YaLTeR/niri/pull/1440

also, today's new overview feature: drag-and-drop into a new workspace between/above/below!

#niri

Overview by YaLTeR · Pull Request #1440 · YaLTeR/niri

Implements #850. Related: #849. This is an overview. It zooms out your workspaces and lets you move your windows around. niri-wip-overview-4.mp4 Open it with a ...

GitHub

POV: GoPro mounted on the xwayland-satellite

#niri

Today: added touch support to the Overview. Somehow, the entire thing just worked first try.

#niri

@YaLTeR
Your work it awesome, love it!
Have you ever seen the EagleMode file manager? This reminds me of it so much, I love it. EagleMode is genuinely useful, and fun. I always wanted a compositor that behaved more like it.

https://www.youtube.com/watch?v=G6yPQKt3mBA
Eagle Mode

YouTube
@YaLTeR the end result looks amazing. Nice job
@YaLTeR forgive my ignorance, vertical workspaces how??
@cienmilojos huh? niri always had vertical workspaces
@YaLTeR yeah this is my first look at niri, so apologies for the ignorance. I've never been into tiling window systems, but this looks cool.
@cienmilojos well, it's the same as GNOME before 40
@YaLTeR the original Mutter machine
@ebassi really?
@YaLTeR back in the Moblin days, we initially wrote metacity-clutter as a branch of metacity and developed it on EeePC 900, Dell Mini 9, and Samsung NC20. Then, when Owen started writing GNOME Shell, we ended up renaming it mutter and moved it under GNOME: https://mail.gnome.org/archives/gnome-shell-list/2009-March/msg00019.html
Metacity, Mutter, GNOME Shell, GNOME-2.28

@YaLTeR That looks soooo smooth 🔥
@YaLTeR sooooo buttery smoooth
@YaLTeR checking yalters progress report is my morning routing 🙂
@YaLTeR This is looking great, excited to use this when it releases!
@YaLTeR are we getting closer to KDE cube??? 
@YaLTeR killer feature. Looking forward to it :)
@YaLTeR Awesome!!! I am looking forward to it

@YaLTeR

Wow, this looks awesome!

@YaLTeR that looks GREAT!

@kde Can we have something like that in #plasma please? 😆

@YaLTeR what ever that is! It’s 😎
@YaLTeR really nice!
One question about Niri though, can it be used as traditional tiling window manager? Scrolling looks good, however some people would prefer not to have it
@su kinda but not really, no

@YaLTeR preparing to switch to niri soon…

this looks awesome!

@YaLTeR I don't see the point in programming if you can't write fun easter eggs! 😂👏
@YaLTeR ​​​​​
@YaLTeR I think this could look even more cool with a parallax effect

@YaLTeR

Works in the nix flake toofor completeness, since it was mentioned, here's the equivalent snippet in niri-flake's options:
{ programs.niri.settings = { window-rules = [ { matches = [{is-floating = true;}]; baba-is-float = true; } ]; }; }
have fun, my Nix-based friends :3

@YaLTeR i came from hyprland and sway and then realized that i used workspaces there primarily to avoid having too many windows on one screen. with niri this is almost never an issue, since there's always some space on the right and on the left. niri's dynamic workspaces are more like actual workspaces, separating different tasks.
@YaLTeR interesting read. Personally, I specifically use niri as alternative to workspaces.
@ju curious. I always use workspaces, be it GNOME, PaperWM or niri
@YaLTeR The example workflow is something I hadn’t thought of, but I really like the idea. It’s almost like a scratch terminal window but for a browser window. It also gave me an idea for a script to have it toggle between the browser workspace and the previous workspace so you don’t have to move them around.

@armerpunkt don't need a script: https://github.com/YaLTeR/niri/wiki/Configuration:-Input#workspace-auto-back-and-forth

For me it's just not as convenient to switch by name/index, I like sticking to up/down

Configuration: Input

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

GitHub

@YaLTeR Oh nice! That’ll work perfect. Thanks!

Yeah I normally just do up and down. This is just a sort of workaround to get a sort of scratch workspace (And I see now there is already a bug about them so I won’t bother you any further on that topic 😉)