Notices by Ivan Molodetskikh (yalter@mastodon.online)

RE: https://mas.to/@zekjur/115835816998094098

wow I didn't realize nvidia had so many basic unsupported DRM properties

(also in case someone wants to suggest niri: we don't have TILE support either, and I don't have a monitor to add/test it, so...)

Related: how do distros track these build-time dependency checks? E.g. my app did a build-time check and used the GTK < 4.12 code path, then the distro updated GTK to 4.12, so now my app needs to be rebuilt to take advantage of the new API. How is this tracked?

I guess this question is more relevant for rolling-release distros, but it's very possible for a build-time check to test for a minor version which would be updated even in a non-rolling-release distro.

#linux #fedora

One thing I'm missing in the Rust ecosystem of bindings to C libraries is easy conditional compilation based on the build-time library version. Something like the GTK_CHECK_VERSION() macros in C.

In Rust bindings, it's common to expose some baseline version API, then have feature flags to expose (and depend on) newer versions of the library. But there's no simple way to do, as a downstream user:

#[cfg(have_gtk_4_12)]
use_new_api();
#[cfg(not(have_gtk_4_12))]
fallback_with_old_api();

#rust

@cnx even on minor bumps?

I finished and merged the horizontal drag interaction tweak from a previous post. It's very handy but can also be annoying when you want to move windows across monitors, so on mouse I restricted it to headerbar dragging (so, not Mod+LMB and not in the overview).

On touch however, it works for both headerbar dragging, and for Mod+Touch, so you can now easily scroll the view around.

I also added the thing where you can touch with another finger to switch between floating and tiling.

#niri

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)

#niri

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

#niri

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 :blobmiou:

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.

#niri

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.

#niri

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.

#niri

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!

#niri

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.

#niri

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

Also 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

#niri

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

#niri

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

#niri

We've hit 15k stars on the niri repo!! :ablobcatheartsqueeze: :ablobcatheartsqueeze:

#niri

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.

#niri

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.

#niri

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.

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

#niri