16:23 <skuzzymiglet> ifreund: I've heard river was your first project in Zig, had you worked on window managers before?

16:27 <ifreund> skuzzymiglet: nope! all I'd done with wayland before river was write a screenlocker and patch one bug in wlroots I found annoying

16:28 <ifreund> never did anything significant with X11, looked at it briefly which is what inspired me to switch to wayland/sway in the first place

16:28 <skuzzymiglet> you were familiar with wlroot though, right?

16:28 <skuzzymiglet> s/root/roots

16:29 <ifreund> not really, I'd never looked at its code before I patched that bug

16:30 <ifreund> and didn't look at it again until I started working on river

16:39 <skuzzymiglet> when I open fuzzel, river aborts

16:39 <skuzzymiglet> both directly and through the keybinding

16:40 <skuzzymiglet> it only seems to happen when I have a second hdmi screen attached

16:40 <skuzzymiglet> and it doesn't matter what screen I launch it on

16:41 <ifreund> hrm, fuzzel aborts when run in a nested session...

16:46 <skuzzymiglet> nested session?

16:48 <ifreund> running river inside river

16:49 <skuzzymiglet> so when you connect another display, is it it's own compositor?

16:53 <ifreund> dnkl: opened a fuzzel issue for you with a stack trace :)

16:53 <dnkl> ifreund: skuzzymiglet: let me know if there's anything I can help wit.... and there I got the mail

16:53 <dnkl> 😂

16:53 <skuzzymiglet> man I love when bugs are that easy to reproduce

16:54 <ifreund> skuzzymiglet: no, a completely separate river session run using wlroots' wayland backend

16:54 <ifreund> which is very useful for testing bugs involving multiple outputs on a machine with only a single monitor

16:55 <dnkl> Looks like fuzzel doesn't get output info. Something with the wl_output interface?

16:56 <ifreund> looks like wlroots is sending 0 width and heigth in wl_output.geometry

16:57 <ifreund> foot seems to handle it fine though

16:59 <dnkl> Foot might have better fallback handling...

16:59 <ifreund> WAYLAND_DEBUG log: https://0x0.st/-8z9.txt

17:00 <dnkl> On the phone right now, but will fix the crash in fuzzel latef

17:00 <ifreund> much appreciated :)

19:44 <leon-p> Do we explicitly close layer surfaces before disabling an output? Sway does and I was wondering about whether other compositors do the same or just let the layer shell client destroy the surface themselves.

19:45 <yyp> I think we should

19:45 <leon-p> based on what?

19:45 <yyp> What if a client messes up with a heavy surface not destroying it - that's a memory leak

19:45 <skuzzymiglet> skimming the source it seems river does

19:46 <skuzzymiglet> disclaimer: I haven't read the source before :)

19:46 <leon-p> yyp: generally a compositor should not workaround client bugs

19:46 <leon-p> skuzzymiglet: thanks, probably should have done that in the first place :)

19:46 <skuzzymiglet> https://github.com/ifreund/river/blob/master/river/Root.zig#L150

19:48 <leon-p> I'll have to re-read the protocol again, because I wonder if it explicitly enforces this.

19:48 <ifreund> yes we do, which is the right thing to do

19:53 <skuzzymiglet> ripgrep is really good for that type of thing

19:54 <skuzzymiglet> I regularly run it on the void-packages repo and it's pretty damn fast

20:03 <skuzzymiglet> is `error.SeatNotAdverstised` a typo?

20:03 <yyp> I don't think so

20:05 <skuzzymiglet> adverstised?

20:05 <skuzzymiglet> does it mean something different to advertised?

20:09 <ifreund> yes that's a typo