Using a coding language for configs

[Vermoot]

Hi there!
Looking at #391 I found myself dearly wishing niri (and more compositors/WMs generally) used actual code and an API for configs, something like AwesomeWM.
The focus-next-or-first feature is something I actually did in my AWM config even though it wasn't implemented in the WM itself, because the API and code config allowed me to do so.

In pretend lua, it could look like this:

require("niri")
w = niri.ws

function ws_next_cycling()
  ws_list = w.workspaces()
  if w.active().index == #ws_list then -- Currently active WS is the last one
    w.focus(1)
  else
    w.focus(w.active().index + 1)
  end
end

Of course I understand doing this rather than parsing a config like niri does now is a huge amount of work and a very different paradigm altogether, but I'm curious to read your thoughts about it?

[YaLTeR]

Well, this is a spectrum of course. Awesome WM is quite extensive in how much is expressed in Lua. I guess it's a question of project goals.

For niri this complete configurability isn't a goal, rather I focus on the scrollable tiling layout and try to make it work well. Exposing a big API like Awesome WM would be a ton of work, and a ton of unfortunate restrictions on what I can actually do in the internals. Plus, writing the logic in Rust catches some classes of errors at compile time.

[Vermoot]

lua isn't a prerequisite of course. For example Pinnacle aims at allowing users to write their config in either lua or rust.

There's also the example of xmonad, which is written in haskell, and as I understand it lets the user "finish writing the WM", which is their config, written in haskell.

I'd be very happy with something like this, where niri has "unfinished", or at least exposed parts, left to the user to write in Rust, as their config.

[YaLTeR]

Regardless of language, you still need to commit to a big API surface. Maybe that works better for more tried and true desktop paradigms; for niri I'm still frequently doing big API changes in the layout code. With more upcoming, e.g. for the floating layer.

[morenathan]

#411 I think addresses this idea. If you hook into a stream of IPC events and then "respond" to the ones you want, this would kill 2 birds with one stone.

As long as the IPC events are parsable and clear and the ability to manipulate Niri back with actions is functionally useful.

This also seems infinitely more simple to implement than embedding an alternative language parser into Niri itself, just for the sake of configuration.