Decided to try writing a Wayland compositor for fun.
-
Had to show slides a few times for uni lately, which motivated me to add this next feature.
Windowed fullscreen, also known in other WMs as fake or detached fullscreen, makes the window think that it went fullscreen, while in reality keeping it as a normal window. Useful in combination with apps like Google Slides to hide the browser UI without taking up the whole screen, especially on ultrawide monitors.
Wiki section: https://github.com/YaLTeR/niri/wiki/Screencasting#windowed-fakedetached-fullscreen
This one seems simple, but actually turned out quite tricky to implement.
I wrote niri code under the assumption that the fullscreen state does not apply immediately: we send a configure to the window, then only at a later point it commits in response. Windowed fullscreen breaks this because in some cases it can apply instantly (going from real to windowed fullscreen needs no state change from the window).
-
This one seems simple, but actually turned out quite tricky to implement.
I wrote niri code under the assumption that the fullscreen state does not apply immediately: we send a configure to the window, then only at a later point it commits in response. Windowed fullscreen breaks this because in some cases it can apply instantly (going from real to windowed fullscreen needs no state change from the window).
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.
-
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.
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!
-
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!
-
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
-
-
started working on an Overview for niri. very wip, lots to do, got some basic rendering and dragging working though
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
-
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
-
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
-
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!
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
-
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
-
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!
-
Today: added touch support to the Overview. Somehow, the entire thing just worked first try.
-
After some more fixes, and a long rebasing session, I merged the Overview! Please give it more testing using your nearest niri-git package.
-
Ppl naturally want to put something in the Overview backdrop, like a blurred version of the wallpaper (see how popular Blur My Shell is). Orthogonally, some ppl want the wallpaper to be static, rather than move with workspaces (it can be distracting).
I'm not prepared to dive head-first into image rendering and blur shaders yet, so I made it possible to put a layer surface into the backdrop. This enables both of those cases, likely even more cool things!
https://github.com/YaLTeR/niri/wiki/Overview#backdrop-customization
-
Ppl naturally want to put something in the Overview backdrop, like a blurred version of the wallpaper (see how popular Blur My Shell is). Orthogonally, some ppl want the wallpaper to be static, rather than move with workspaces (it can be distracting).
I'm not prepared to dive head-first into image rendering and blur shaders yet, so I made it possible to put a layer surface into the backdrop. This enables both of those cases, likely even more cool things!
https://github.com/YaLTeR/niri/wiki/Overview#backdrop-customization
-
Today, screenshot UI updates! Implemented tablet and touchscreen input for area selection (at long last). And, added a small clickable capture button, so screenshots can now be confirmed tablet-, touch-, or mouse-only!
After long 3 months of work, I'm glad to release niri v25.05 with the Overview, screenshot UI tablet and touch support, dynamic screencast target and windowed fullscreen, IPC pick-window and pick-color, window urgency, and lots of other things!
Release notes prepared for your reading pleasure as always: https://github.com/YaLTeR/niri/releases/tag/v25.05
-
After long 3 months of work, I'm glad to release niri v25.05 with the Overview, screenshot UI tablet and touch support, dynamic screencast target and windowed fullscreen, IPC pick-window and pick-color, window urgency, and lots of other things!
Release notes prepared for your reading pleasure as always: https://github.com/YaLTeR/niri/releases/tag/v25.05
-
Tagged a niri v25.05.1 hotfix, fixing kitty quick access terminal, numlock, and some jank with hidden cursor.
Alright after some much needed rest, I set out to deal with the thing everyone has to bump into when setting up niri: some way to use Xwayland. I am still very much *not* planning to integrate Xwayland directly, but with this PR (and an accompanying xwayland-satellite PR), niri will create the X11 sockets and autostart xwl-s on demand, all out of the box with zero configuration. So, it'll work just like other compositors, but with xwl-s instead of direct Xwayland.
