Decided to try writing a Wayland compositor for fun.
-
Screen reader announcement demo bc apparently you can't attach video and image at once
Fullscreen refactor pt. 1: track pending vs. current fullscreen state for columns, avoid vertical jump when waiting for window to commit a new buffer.
-
Fullscreen refactor pt. 1: track pending vs. current fullscreen state for columns, avoid vertical jump when waiting for window to commit a new buffer.
Fullscreen refactor pt. 2: added un/fullscreen animations. This one involved quite a lot of moving parts actually, so looking for testing.
-
Fullscreen refactor pt. 2: added un/fullscreen animations. This one involved quite a lot of moving parts actually, so looking for testing.
Fullscreen refactor pt. 3 turned out to be a refactor of a good chunk of core Smithay xdg-shell/layer-shell/session-lock logic, making it more correct. The fullscreen PR in niri now includes that Smithay refactor, and needs testing even more than before
https://github.com/YaLTeR/niri/pull/2333#issuecomment-3263990200
Specifically, the refactor makes Smithay correctly track the last acked configure for each commit, also enforces the "must ack before committing first buffer" protocol rule.
-
Fullscreen refactor pt. 3 turned out to be a refactor of a good chunk of core Smithay xdg-shell/layer-shell/session-lock logic, making it more correct. The fullscreen PR in niri now includes that Smithay refactor, and needs testing even more than before
https://github.com/YaLTeR/niri/pull/2333#issuecomment-3263990200
Specifically, the refactor makes Smithay correctly track the last acked configure for each commit, also enforces the "must ack before committing first buffer" protocol rule.
With the fullscreen refactors in place, I got started on the thing that I wanted to do all along: maximize.
Niri didn't support normal Wayland maximize because it's very similar (yet slightly different) to our full-width columns—and can't be bound to our full-width state either. However, after plenty of requests, and thinking about it, I reconsidered. Henceforth, the maximize buttons and double-clicking on the titlebars will do the expected thing.
Details in PR: https://github.com/YaLTeR/niri/pull/2376
-
With the fullscreen refactors in place, I got started on the thing that I wanted to do all along: maximize.
Niri didn't support normal Wayland maximize because it's very similar (yet slightly different) to our full-width columns—and can't be bound to our full-width state either. However, after plenty of requests, and thinking about it, I reconsidered. Henceforth, the maximize buttons and double-clicking on the titlebars will do the expected thing.
Details in PR: https://github.com/YaLTeR/niri/pull/2376
My Smithay refactors were merged: the big one mentioned above, plus a fix for popup stacking order (e.g. open popup, then open tooltip also from the toplevel itself), plus a fix for root popup grabs from Qt layer-shell surfaces. All of this along with fullscreen refactors and animations is now merged to niri main. (maximize is still wip)
-
My Smithay refactors were merged: the big one mentioned above, plus a fix for popup stacking order (e.g. open popup, then open tooltip also from the toplevel itself), plus a fix for root popup grabs from Qt layer-shell surfaces. All of this along with fullscreen refactors and animations is now merged to niri main. (maximize is still wip)
There's been a long-standing request to add config includes to niri. They're useful for config organization, but also for custom desktop shells to be able to change colors without having to edit the main user's config.
Today I finished the first step towards this: a many-days-long refactor that makes the main config part, layout, mergeable, i.e., able to be combined from multiple parts. And building on this, per-output/workspace overrides.
https://github.com/YaLTeR/niri/pull/2449
Testing wanted here!
-
There's been a long-standing request to add config includes to niri. They're useful for config organization, but also for custom desktop shells to be able to change colors without having to edit the main user's config.
Today I finished the first step towards this: a many-days-long refactor that makes the main config part, layout, mergeable, i.e., able to be combined from multiple parts. And building on this, per-output/workspace overrides.
https://github.com/YaLTeR/niri/pull/2449
Testing wanted here!
Our config system is declarative, rather than command-like, which means that we parse the config into a tree of data types instead of reading lines and applying them one-by-one. This design requires a lot of work to properly support includes, but in turn we get atomic and selective reloading (if output part of the config didn't change, we don't override your transient output adjustments), better error messages and no problems with things like "spawn-at-startup" that should only work once.
-
Our config system is declarative, rather than command-like, which means that we parse the config into a tree of data types instead of reading lines and applying them one-by-one. This design requires a lot of work to properly support includes, but in turn we get atomic and selective reloading (if output part of the config didn't change, we don't override your transient output adjustments), better error messages and no problems with things like "spawn-at-startup" that should only work once.
After several more days of work, I fully finished config includes. All config sections merge together, live-reloading watches all included files (even if they fail to parse), error messages work across files, documentation is written.
https://github.com/YaLTeR/niri/pull/2482
Once again, this needs testing! There must be NO breakage to existing configs, so if something breaks, I want to know about it to fix it.
-
After several more days of work, I fully finished config includes. All config sections merge together, live-reloading watches all included files (even if they fail to parse), error messages work across files, documentation is written.
https://github.com/YaLTeR/niri/pull/2482
Once again, this needs testing! There must be NO breakage to existing configs, so if something breaks, I want to know about it to fix it.
I merged config includes, along with per-output and per-workspace layout config overrides. Play around with them at your nearest niri-git package.
- https://yalter.github.io/niri/Configuration%3A-Include.html
- https://yalter.github.io/niri/Configuration%3A-Outputs.html#layout-config-overrides
- https://yalter.github.io/niri/Configuration%3A-Named-Workspaces.html#layout-config-overridesAlso merged ignore-drm-device which should let you passthrough a GPU to VMs: https://yalter.github.io/niri/Configuration%3A-Debug-Options.html#ignore-drm-device
-
I merged config includes, along with per-output and per-workspace layout config overrides. Play around with them at your nearest niri-git package.
- https://yalter.github.io/niri/Configuration%3A-Include.html
- https://yalter.github.io/niri/Configuration%3A-Outputs.html#layout-config-overrides
- https://yalter.github.io/niri/Configuration%3A-Named-Workspaces.html#layout-config-overridesAlso merged ignore-drm-device which should let you passthrough a GPU to VMs: https://yalter.github.io/niri/Configuration%3A-Debug-Options.html#ignore-drm-device
After a detour to config includes and, again, several days/weeks of work implementing all edge cases and expected behaviors, true window maximize is ready and merged to main. Tricky cases like: windows requesting fullscreen and maximize after opening; windows failing to match the full maximized size; transparent windows with the niri border behind them.
https://yalter.github.io/niri/Fullscreen-and-Maximize.html
Give it a try! Ngl I mostly switched to maximize just because I'm too lazy to reach the keyboard for Mod+F.
-
After a detour to config includes and, again, several days/weeks of work implementing all edge cases and expected behaviors, true window maximize is ready and merged to main. Tricky cases like: windows requesting fullscreen and maximize after opening; windows failing to match the full maximized size; transparent windows with the niri border behind them.
https://yalter.github.io/niri/Fullscreen-and-Maximize.html
Give it a try! Ngl I mostly switched to maximize just because I'm too lazy to reach the keyboard for Mod+F.
One cool thing I noticed about true maximize is that apps like GIMP or Inkscape or Blender, that really want all available space, maximize themselves at startup, so you don't have to window-rule them manually in your config
-
One cool thing I noticed about true maximize is that apps like GIMP or Inkscape or Blender, that really want all available space, maximize themselves at startup, so you don't have to window-rule them manually in your config
microsoft niri
-
microsoft niri
Small change on niri-git for people using the foot terminal with CSD, or other apps that constrain their sizes to a grid: niri will now match the default column width to a preset width when a window opens. So opening foot sized "proportion 0.5" and then pressing Mod+R will switch you to the next preset width, even if foot actually opened slightly smaller to match its terminal grid. Before the change, the first Mod+R would pick the same "proportion 0.5" in this case and "do nothing".
-
Small change on niri-git for people using the foot terminal with CSD, or other apps that constrain their sizes to a grid: niri will now match the default column width to a preset width when a window opens. So opening foot sized "proportion 0.5" and then pressing Mod+R will switch you to the next preset width, even if foot actually opened slightly smaller to match its terminal grid. Before the change, the first Mod+R would pick the same "proportion 0.5" in this case and "do nothing".
Also, experimenting with this interaction tweak on a branch: what if dragging tiled windows horizontally scrolled the view instead of dragging them "out"? This makes it possible to scroll the view mouse-only without going through the Overview (the zooming gets quite tiring when it's frequent), and makes it possible to scroll the view touch-only. To drag the window out of the layout, you can still drag it downward.
-
Also, experimenting with this interaction tweak on a branch: what if dragging tiled windows horizontally scrolled the view instead of dragging them "out"? This makes it possible to scroll the view mouse-only without going through the Overview (the zooming gets quite tiring when it's frequent), and makes it possible to scroll the view touch-only. To drag the window out of the layout, you can still drag it downward.
Added a small "Quick Start" to the niri docs that gets you going with niri + DMS in three commands:
https://yalter.github.io/niri/Getting-Started.html#quick-start
Tested the Fedora ones on a fresh VM, worked out nicely, getting me into a session with a very functional desktop shell.
-
Added a small "Quick Start" to the niri docs that gets you going with niri + DMS in three commands:
https://yalter.github.io/niri/Getting-Started.html#quick-start
Tested the Fedora ones on a fresh VM, worked out nicely, getting me into a session with a very functional desktop shell.
Currently in the middle of finishing up the Alt-Tab PR for niri: https://github.com/YaLTeR/niri/pull/1704
Got most things working as I'd like, though still plenty of fixes and clean-ups left. Fully live window previews with block-out-from support and fading title labels.
There's some interesting design differences compared to other desktops: on niri I expect it's common to have multiple terminals open, so Alt-Tab must go by windows (not by apps) and must show previews big enough to pick the right one.
-
Currently in the middle of finishing up the Alt-Tab PR for niri: https://github.com/YaLTeR/niri/pull/1704
Got most things working as I'd like, though still plenty of fixes and clean-ups left. Fully live window previews with block-out-from support and fading title labels.
There's some interesting design differences compared to other desktops: on niri I expect it's common to have multiple terminals open, so Alt-Tab must go by windows (not by apps) and must show previews big enough to pick the right one.
We've hit 15k stars on the niri repo!!
-
We've hit 15k stars on the niri repo!!
Just merged Alt-Tab to main, shortly arriving at your nearest niri-git. Comes with plenty of ways to tweak it if you want [1], and a focus timestamp in the IPC [2] that lets shell devs make their own recent windows switchers.
[1]: https://yalter.github.io/niri/Configuration%3A-Recent-Windows.html
[2]: https://yalter.github.io/niri/niri_ipc/struct.Window.html#structfield.focus_timestamp -
Just merged Alt-Tab to main, shortly arriving at your nearest niri-git. Comes with plenty of ways to tweak it if you want [1], and a focus timestamp in the IPC [2] that lets shell devs make their own recent windows switchers.
[1]: https://yalter.github.io/niri/Configuration%3A-Recent-Windows.html
[2]: https://yalter.github.io/niri/niri_ipc/struct.Window.html#structfield.focus_timestampDid some work on the TTY backend in niri over the past few days. Merged PR for DisplayLink dock support, added "panel orientation" property read, and, based on cosmic-comp code, implemented the necessary logic to avoid screen blanking. Finally, both at niri startup and when switching TTYs, your screen won't flicker, as long as resolution/refresh rate stay the same.
Even when the screen does blank, it'll go faster, as there's now just one modeset instead of two (clear then draw frame).
-
Did some work on the TTY backend in niri over the past few days. Merged PR for DisplayLink dock support, added "panel orientation" property read, and, based on cosmic-comp code, implemented the necessary logic to avoid screen blanking. Finally, both at niri startup and when switching TTYs, your screen won't flicker, as long as resolution/refresh rate stay the same.
Even when the screen does blank, it'll go faster, as there's now just one modeset instead of two (clear then draw frame).
Took some fighting but I think I've managed to teach the new Alt-Tab to speak to the screen reader
