On Tue, Mar 04, 2025 at 04:53:36PM GMT, Stuart Henderson wrote: > On 2025/03/04 17:46, Landry Breuil wrote: > > Le Tue, Mar 04, 2025 at 05:13:07PM +0100, Tobias Heider a écrit : > > > Hi, > > > > > > here is a new port for niri [1], a scrollable-tiling Wayland compositor > > > heavily inspired by the PaperWM extension for Gnome. > > > > > > This one is a little different than our existing wayland compositor ports > > > since it doesn't use wlroots but smithay [2] as its underlying compositor > > > library. > > > > > > Smithay is written in rust and pulls in quite a few dependencies, I had to > > > resort to some hacks to make it pick up the patched OpenBSD compatible > > > versions since most patches haven't found their way into an upstream > > > release > > > yet. In the current version I fetch niri itself and all the patched > > > dependencies from my forked trees on github. I already got some of them > > > merged upstream so I'm optimistic that we can swtich over to an official > > > release in the near future. > > > > > > Looking forward to get some feedback. > > > Some open questions: > > > Is there a better way to handle the rust dependencies? > > > Would it make sense for a large rust package such as smithay to be a > > > separate > > > port? > > > > if that's installed as a lib that can be used by other ports, yes. if > > it's only to ship the source as a buil dependency, i dont think it fits > > well with the rust ecosystem.. > > That would just be a copy of the source code, and wouldn't be any use > in ports. The only time we have those is for special cases (like > rust-openssl-tests which includes rust src and is used for regression > testing).
I was thinking more like a static library that is only used as a build dependency but I'm not sure if that is possible in rust. > > > > I used upstream_version.date for our port version, is there a better > > > solution? > > > > that's what i also usually do, or 'pl0' for 'patchlevel' when you have > > modifications 'on top' of upstream. > > > > the port itself already looks quite good, as for the configuration file > > you might want to @sample examples/niri/default-config.kdl to > > /etc/niri/config.kdl so that it's there by default. > > > > generally speaking, i think it's good to have wayland compositors in > > port that are not based off wlroots, allows for wider testing. > > > > I've done approximately 0 with wayland but that makes sense to me. >