02:35 <mvnx> Hello! I'm trying to package River for Guix. Wondering if this error makes sense to anyone here. Not sure if it's a more general Zig error or a River error but it looks like there's an issue (at least with my setup) on `scanProtocol` in `zig-wayland`. Maybe a path issue? https://paste.debian.net/hidden/594546b1/

03:02 <waleee> mvnx: I think that that ultimately is because 'zig build' tries to write to the immutable /gnu/store directly

03:02 <waleee> hm or not, didn'

03:03 <waleee> *t check out the overflowed text in that paste

03:20 <mvnx> Thanks for taking a look. :)

03:36 <waleee> mvnx: have you taken a look at the nix expression for river? https://github.com/NixOS/nixpkgs/blob/master/pkgs/applications/window-managers/river/default.nix

03:38 <waleee> a missing equivalent of fetchSubmodules might be a problem in guix

03:38 <waleee> s/in/for/

03:41 <mvnx> I have, that's what I modelled my Guix package after. Submodules are being pulled in - I set a flag for that and in the stack trace it references source code in zig-wayland (one of river's submodules).

03:56 <waleee> noticed it now that you mentioned it. But the lines above it in the stack trace makes me wonder if the error is because zig-wayland maybe can't find the xml-files for the wayland-protocols?

04:44 <mvnx> That's kind of what it sounds like, yeah. Thanks - gives me something to dive into.

04:53 <mvnx> Yeah that was it - version issues with wayland-protocols. I made it past there and on to the next version mismatch for wlroots. :) Progress is progress.

05:48 <plumeus> mvnx, have you also looked at the zig-build-system?

05:49 <plumeus> https://issues.guix.gnu.org/60889 has yet to be merged but I think it's better than what NixOS has.

05:49 <apoorv569[m]> I have this keybind added to my river config, riverctl map normal Super Return spawn 'alacritty'

05:49 <apoorv569[m]> but it doesn't look like it works

05:50 <apoorv569[m]> though if i open a terminal via dmenu then run this command

05:50 <apoorv569[m]> then the keybind works

05:52 <angry_vincent> it will work after you relaunch river

05:52 <angry_vincent> to change on the fly type whole line in terminal

05:52 <mvnx> plumeus: No! I hadn't seen it. Yeah the build system isn't in master yet but I am looking forward to it. Thanks for the heads up.

05:52 <angry_vincent> `riverctl map normal Super Return spawn 'alacritty'` in alacritty

05:55 <plumeus> Ekaitz (the person who wrote the Guix patch) is also sometimes online on the Zig IRC and he said he would respond to mails if you have any questions. Although most of it seems straight forward.

05:58 <apoorv569[m]> <angry_vincent> "it will work after you relaunch..." <- I have logged out and logged back in multiple times. Even rebooted the system. Still won't work.

06:14 <plumeus> Wait, do you have multiple keybinds associated with it?

06:17 <plumeus> https://github.com/riverwm/river/blob/master/example/init#L40

06:33 <apoorv569[m]> OK, Fixed. There was another thing using the same keybind.

11:41 <bw> what's the easiest way in river to tell if a window is using native wayland or xwayland?

12:06 <ifreund> bw: I'm fond of using xeyes for that

12:07 <ifreund> if the eyes can "see" the window it's using xwayland

12:07 <bw> hah

12:58 <pinpoxIRC> Slightly offtopic, but I wrote a wallpaper-generator for awesomeWM. Now that I have switched to river, I was thinking about re-implementing it in Zig. Does anyone know a good drawing/painting library for Zig?

12:58 <pinpoxIRC> This is my original code in lua https://github.com/pinpox/wallpaper-generator

13:32 <p00f1> dnkl: can fuzzel launch apps in the tag they were selected from? sometimes firefox takes a while - i switch to another tag and then firefox is here

13:39 <dnkl> p00f1: that's not up to fuzzel

13:39 <ifreund> p00f1: fuzzed alone can't make that happen unfortunately, it would need cooperation from river and ideally firefox as well

13:39 <dnkl> but fuzzel implements xdg activation, which is a prerequisite for the compositor to be able to do it

13:40 <p00f1> I see

13:40 <ifreund> leon-p was looking into this the other day

13:42 <ifreund> The xdg-activantion based approach does require firefox (or maybe gtk?) to activate before it maps its toplevel

14:26 <leon-p> ifreund, p00f: I looked into it, the problem is that when an application activvates before map, we don't have a view yet, if I am not mistaken.

14:27 <leon-p> Also I think that for activate after map we could also move, if the token came from river itself, like `riverctl spawn -current-tags firefox`

14:28 <leon-p> a token from a different client is not possible right now AFAICT, because I don't see a way to hook into that mechanism

14:31 <ifreund> leon-p: yeah, that's another wlroots API limitation that we should hopefully get fixed eventually: https://gitlab.freedesktop.org/wlroots/wlroots/-/issues/3608

14:32 <ifreund> feel free to drop a comment there if you want to explain that other use-case

14:32 <leon-p> neat, seems like my unique identifier idea for ext-foreign-toplevel-list seems to have been accepted, so maybe we can have a simple window switcher after all

14:32 <leon-p> ifreund: sure, will check it out

17:34 <leon-p> activating a surface should only have been allowed after it has been given a role :/

17:35 <leon-p> i guess we could have a list of activated surfaces that don't have a role yet we could check against when creating a toplevel, but that is awkward

18:19 <leon-p> I mean, it works, I just don't really like what I had to do to make it work: https://github.com/riverwm/river/pull/815

18:21 <ifreund> leon-p: dont have time to take a real look yet, but I'm not sure it makes sense to have this be configurable

18:21 <ifreund> current tags is the intended behavior, the fact that it doesn't work properly for slow clients is a bug

18:21 <leon-p> true

18:22 <leon-p> what's missing rn is a way for stored tokens to expire