07:46 <LarstiQ> leon-p: thanks for your river-config (and in particular the layout.scm), I keep finding useful bits and building on it. My `all-layouts` was getting a bit long to cycle through, I've now added a `switch-layout <some-layout>` command, implemented the layouts I was missing in riverguile and ready to ditch running multiple layout generators

07:50 <LarstiQ> oh and also thanks for riverguile itself of course :)

08:40 <maralorn> leon-p: I am using riverguile now. Really nice.

08:40 <maralorn> I think I will upstream my package to nixos.

08:40 <maralorn> Do you plan on having something like releases sometime soon?

08:42 <maralorn> However my scheme foo is not very strong yet. I was thinking about writing e.g. a function like "hsplit :: Box -> (Box, Box)" but since Boxes are represented as lists the implementation feels inelegant.

09:13 <LarstiQ> maralorn: I basically ported https://github.com/areif-dev/river-bsp-layout/blob/main/src/lib.rs#L86, don't know if that would meet your elegance standards but it doesn't look too bad to me :)

09:13 <LarstiQ> https://git.sr.ht/~leon_plickat/river-config/tree/master/item/river/layout.scm#L21-25 could also be a starting point

09:14 <maralorn> Ah, nice examples. Thanks.

09:15 <maralorn> Well that function is fine. But it takes all parameters as arguments.

09:15 <maralorn> Although is there a trick to pass a list as parameters to a function?

09:16 <maralorn> btw. does -> and : in function names have any semantic in the language or is that just a convention (by you)?

09:18 <LarstiQ> convention, see `Naming conventions` in https://standards.scheme.org/official/r5rs.pdf. Neither of those linked bits of code are written by me

09:18 <LarstiQ> maralorn: are you thinking of apply?

09:18 <maralorn> Sounds like it.^^

09:19 <LarstiQ> page 32 of r5rs, e.g. (apply + (list 3 4)) => 7

09:19 <maralorn> Excellent

09:20 <maralorn> Last time I wrote scheme was in 2012.^^

10:55 <leon-p> maralorn: (split-box box) could return a list of two boxen ((x y w h) (x y w h)) and then you can just map other layouts over it

10:55 <leon-p> it's also what I did in my config. I wrote a bunch of layout primitives and then arranged sublayouts by a metalayout.

10:56 <leon-p> I might do a release in the next week or so

11:25 <LarstiQ> leon-p: cool!

14:34 <tiosgz> i have finally got around to set a bright background and check novakane's recent issue

14:35 <tiosgz> just opening a bunch of feet and closing them reproduces it about half the time

14:36 <tiosgz> (plus there's a fcitx "workaround" forcing me to release and again press ctrl for ^d-ing, but that's unrelated to this)

14:36 <tiosgz> ifreund: ^^^

15:02 <angry_vincent> leon-p: is there a visual representation of riverguile layouts? just trying to understand it

15:07 <LarstiQ> angry_vincent: you mean for arbitrary layouts?

15:07 <LarstiQ> riverguile itself doesn't come with any layouts, that's configuration that the user provides

15:07 <angry_vincent> that's one i want to see

15:14 <angry_vincent> they are commented in layout.scm, just would be nice to see them in action, if possible

15:16 <LarstiQ> ah, you mean his own river-config ones?

15:17 <angry_vincent> yes

15:17 <angry_vincent> or anyone, who can provide that

15:18 <LarstiQ> hmm, I do use riverguile but with my own config

15:18 <LarstiQ> really the easiest way to see it is just run it

15:19 <angry_vincent> sure. i understand

15:19 <LarstiQ> since it's guile under the hood it would be fun to make a layout visualizer

15:21 <LarstiQ> would need to handle the user-command and layout-demand events, and have a little repl to allow sending those plus control over how many windows to lay out

17:49 <novakane> tiosgz: hmm I need to try with a dark background then, that's weird

17:50 <novakane> i feel like we already had something that happened only on light backgrounds, can't remember what though

17:58 <ifreund> novakane: it's probably just a lot less visible with a dark background

18:00 <ifreund> novakane: ah yep, I can reproduce frame imperfection with a dark terminal on a light background on my laptop

18:00 <ifreund> will have a look

18:01 <ifreund> thanks tiosgz for reminding me to change my background color :)

18:04 <ifreund> damn, this fixes it https://0x0.st/H6_r.diff

18:04 <ifreund> I hate this signal ordering stuff

18:04 <ifreund> I guess my workaround in handleUnmap() broke with wlroots 0.17

18:07 <novakane> oh, damn, it's just that

18:07 <novakane> well glad I'm not crazy with this imperfect frame though :P

18:08 <ifreund> indeed :)

18:13 <novakane> I guess a light background test is needed in river now

18:57 <leon-p> I think there is a bug in the build-system somewhere: I can build river master just fine, but when trying to launch it, it complains about libliftoff not being installed. The build system should catch that, no?

18:57 <leon-p> IIRC that's a wlroots build-options. Maybe zig-wlroots should try to detect that? Wasn't there a header we can include to check for features?

19:03 <ifreund> leon-p: hmm, I don't think river needs to or should do anything different if wlroots was built with libliftoff support or not

19:03 <ifreund> it's only used interanally to wlroots and doesn't affect the wlroots API surface

19:03 <ifreund> if you built wlroots with libliftoff enabled you need libliftoff at runtime

19:04 <ifreund> otherwise you don't

19:04 <leon-p> I haven't build it, I am using the ones from the repos for once

19:10 <ifreund> leon-p: huh, what's the exact error message you get?

19:11 <leon-p> the typical linker error message: ./zig-out/bin/river: error while loading shared libraries: libliftoff.so.0: cannot open shared object file: No such file or directory

19:11 <leon-p> Maybe I borked my local install somehow

19:12 <ifreund> it certainly sounds like an issue with your wlroots/system install

19:12 <ifreund> neither my river or wlroots binary link against libliftoff

19:13 <ifreund> and things work fine

19:13 <leon-p> and I was so excited about being able to use wlroots from the repos because it would allow me to avoid weird behaviour...

19:14 <ifreund> hah, are you sure you don't have some leftover bit of your non-repo wlroots install around?

19:14 <ifreund> you're on arch right?

19:14 <ifreund> it doesn't look like they link libliftoff... https://archlinux.org/packages/extra/x86_64/wlroots/

19:16 <leon-p> wow, seems like I'll be having a fun afternoon

19:17 <leon-p> yeah thanks, I'll be back once I figure this out...

19:26 <leon-p> rm'ing things from /usr/local/lib feels wrong, but now it works

20:11 <novakane> no more imperfect frames \o/

20:54 <leon-p> finally fixed the keyboard group bug and also made identifier matching use globber, which should make using keyboard groups a lot more pleasant

20:58 <ifreund> very nice!

20:59 <ifreund> I've been wondering if we shouldn't default to putting all keyboards on a seat in a group tbh

20:59 <ifreund> is there a case in which that's not the right thing to do?

20:59 <leon-p> no idea, TBH

21:00 <leon-p> I guess we can just do it and if someone complains change it back?

21:00 <leon-p> although I suppose if we ever have per-keyboard layouts or maps, that would not work

21:01 <ifreund> ah, true

21:01 <ifreund> per keyboard layouts are something we should probably support