Decided to try writing a Wayland compositor for fun.
-
The window opening animation is now live as part of niri v0.1.2: https://github.com/YaLTeR/niri/releases/tag/v0.1.2
I'm really looking forward to more animations, but wow they sure do need a lot of care to get right in all the edge cases.
Also, I added a way to programmatically invoke compositor actions, and turns out that's quite useful for making video demos!
-
For a bit of fun I added gradient borders to niri. One of the visual tests for it turned out a bit mesmerizing to look at
Tagged niri v0.1.3: https://github.com/YaLTeR/niri/releases/tag/v0.1.3
This one has much improved touchpad gestures with inertia, springs, rubberbanding and everything else I copied from libadwaita, my primary source for things that feel good
Also thanks @alice for helping and giving feedback on the gestures and for giving a try to the touch support!
-
Tagged niri v0.1.3: https://github.com/YaLTeR/niri/releases/tag/v0.1.3
This one has much improved touchpad gestures with inertia, springs, rubberbanding and everything else I copied from libadwaita, my primary source for things that feel good
Also thanks @alice for helping and giving feedback on the gestures and for giving a try to the touch support!
Just implemented something I've had in mind for a while: compositor-side blocking out of windows from screencasts! The compositor is the perfect place to do this since it can replace the window contents in the render tree, which will work fine with any kind of overlapping, transparency, etc. AND it will work with anything that records the screen through the portal, be it OBS or video meeting, or whatever.
-
Just implemented something I've had in mind for a while: compositor-side blocking out of windows from screencasts! The compositor is the perfect place to do this since it can replace the window contents in the render tree, which will work fine with any kind of overlapping, transparency, etc. AND it will work with anything that records the screen through the portal, be it OBS or video meeting, or whatever.
There's actually an important edge case here: if you open the screenshot UI while recording the monitor, then the screenshot UI preview will show the window, and OBS, recording the screenshot UI preview, will hence also show the window. There are trade-offs here for how you want this to work; for now I put a big warning around the option, and added a stricter mode that blocks out the window from ANY screen capture (which means you can't screenshot it).
-
There's actually an important edge case here: if you open the screenshot UI while recording the monitor, then the screenshot UI preview will show the window, and OBS, recording the screenshot UI preview, will hence also show the window. There are trade-offs here for how you want this to work; for now I put a big warning around the option, and added a stricter mode that blocks out the window from ANY screen capture (which means you can't screenshot it).
I think for the built-in screenshot UI this is solvable with one more layer of indirection (render the screenshot UI preview itself twice, once for screencasts, and once for the monitor). However, for third-party screenshot annotation tools, this will still be a problem.
-
I think for the built-in screenshot UI this is solvable with one more layer of indirection (render the screenshot UI preview itself twice, once for screencasts, and once for the monitor). However, for third-party screenshot annotation tools, this will still be a problem.
Implemented this idea. It means rendering each monitor 3 times always for the screenshot but maybe it's fine? On this laptop 3 monitors × 3 renders takes 2 ms, and there's some unnecessary blocking I forgot to remove.
On the video, note how for me the screenshot UI has Secrets visible, but on the recording afterwards it's always blocked out.
-
Implemented this idea. It means rendering each monitor 3 times always for the screenshot but maybe it's fine? On this laptop 3 monitors × 3 renders takes 2 ms, and there's some unnecessary blocking I forgot to remove.
On the video, note how for me the screenshot UI has Secrets visible, but on the recording afterwards it's always blocked out.
-
Amidst all the fires being put out, niri 0.1.4 which can block out windows from screencasts! https://github.com/YaLTeR/niri/releases/tag/v0.1.4
And also gamma control, focus follows mouse, warp mouse to focus, wheel and touchpad scroll bindings, xdp-gnome 46 support.
Also, every single config option is now documented on the wiki! Which took like an entire week of work (even though I was reusing a lot of my previously written docs in the config). Check it out here: https://github.com/YaLTeR/niri/wiki/Configuration:-Overview
-
Amidst all the fires being put out, niri 0.1.4 which can block out windows from screencasts! https://github.com/YaLTeR/niri/releases/tag/v0.1.4
And also gamma control, focus follows mouse, warp mouse to focus, wheel and touchpad scroll bindings, xdp-gnome 46 support.
Also, every single config option is now documented on the wiki! Which took like an entire week of work (even though I was reusing a lot of my previously written docs in the config). Check it out here: https://github.com/YaLTeR/niri/wiki/Configuration:-Overview
-
Took the whole yesterday and a bit of today, but I've got window closing animations working! These turned out to be tricky because they need storing a snapshot of the surface render tree to draw once the app is gone.
Some apps may start destroying their subsurfaces before the main surface, like alacritty with its sctk CSD, making it very easy to miss parts of the window in the snapshot, and therefore in the closing animation.
Also, windows closing to the left no longer shift the view!
-
Took the whole yesterday and a bit of today, but I've got window closing animations working! These turned out to be tricky because they need storing a snapshot of the surface render tree to draw once the app is gone.
Some apps may start destroying their subsurfaces before the main surface, like alacritty with its sctk CSD, making it very easy to miss parts of the window in the snapshot, and therefore in the closing animation.
Also, windows closing to the left no longer shift the view!
Definitely one of the most complex animations yet: window resizing.
Just the crossfade effect itself took a while to get working with all the window geometries and buffer offsets, and then there's the whole multiple window orchestration with Wayland's asynchronous nature. (I don't do animation transactions yet, that'll be a whole other level of complexity on top.)
Happy with the result though, and it's cool that it seamlessly works with block-out-from screencast.
-
Definitely one of the most complex animations yet: window resizing.
Just the crossfade effect itself took a while to get working with all the window geometries and buffer offsets, and then there's the whole multiple window orchestration with Wayland's asynchronous nature. (I don't do animation transactions yet, that'll be a whole other level of complexity on top.)
Happy with the result though, and it's cool that it seamlessly works with block-out-from screencast.
-
Window movement across columns is now animated too!
These weren't complex per se, but very *finicky*. Spent quite a bit of time chasing down all the offsets and coordinates to add and subtract to avoid jumps, but it seems to all work well now!
-
All the animations, plus VRR, today in niri 0.1.5: https://github.com/YaLTeR/niri/releases/tag/v0.1.5
I also remade the demo video to showcase the animations and some of the newer features!
-
Another tricky feature, rounded corners! Took several days, but I believe I've got a pretty complete implementation.
You (manually) set the window corner radius and whether to force-clip the window. You can set radius per-corner to match GTK 3 apps. It works correctly with subsurfaces, blocked-out windows, transparency, gradient borders, resize and other animations.
Optimization-wise, opaque regions and even overlay plane unredirection work where possible!
-
Another tricky feature, rounded corners! Took several days, but I believe I've got a pretty complete implementation.
You (manually) set the window corner radius and whether to force-clip the window. You can set radius per-corner to match GTK 3 apps. It works correctly with subsurfaces, blocked-out windows, transparency, gradient borders, resize and other animations.
Optimization-wise, opaque regions and even overlay plane unredirection work where possible!
-
Also, we've now got a little #niri setup showcase thread
https://github.com/YaLTeR/niri/discussions/325 -
Added (stole from GNOME Shell as usual) a screen transition action, so now I can finally switch between dark and light in style
(of course, it works with blocked-out windows)
Okay, time for an actually useful feature: interactive mouse resizing (yes, finally). This was, as it goes, quite fiddly to implement, especially since niri has to negotiate with the window during the process.
I also added a double-resize-click (i.e. trigger a resize twice quickly) gesture to reset the window height or to toggle full width. Suggested by FreeFull on our Matrix and worked out very well! Really starting to feel quite nice with mouse.
(still no transactions yet)
-
Okay, time for an actually useful feature: interactive mouse resizing (yes, finally). This was, as it goes, quite fiddly to implement, especially since niri has to negotiate with the window during the process.
I also added a double-resize-click (i.e. trigger a resize twice quickly) gesture to reset the window height or to toggle full width. Suggested by FreeFull on our Matrix and worked out very well! Really starting to feel quite nice with mouse.
(still no transactions yet)
-
Since I'm in a mouse gesture mood today: hooked up the horizontal touchpad swipe to Mod + middle mouse drag and omg it feels so good with the spring deceleration and all
(of course it also correctly avoids the touchpad scaling, so that when using the mouse gesture, the cursor location is always exactly anchored to the view position)
with an a bit of an anticlimactic one though