00:12 <talismanick> ifreund: Any timeline on merging https://github.com/riverwm/river/pull/477 ? I'd really appreciate it

00:14 <talismanick> Also, if I want to build from source to help out, what do I need to do on Void? Does git cloning suffer from the xbps-src template dependency issues?

07:42 <novakane> talismanick: just download a tarball of zig 0.9.1 on zig website and you're good to go on void

07:53 <talismanick> Should I try to build it with 0.10.0 now that that's out?

07:57 <novakane> no, river always use the latest stable version

09:11 <ifreund> talismanick: the main blocker to merging that PR is that I have no way to test the changes myself as I don't have any linux touchscreen hardware :/

09:12 <ifreund> it also needs a bit of cleanup before merge iirc, I can probably find time to get the code in a mergeable state this week but would need someone with hardware to test it

09:31 <NickH> ifreund: I have a Dell XPS 15 with a touchscreen. Would be happy to test.

09:32 <ifreund> cool, it would be good to finally have that merged. Will hopefully find time for the code later today

09:34 <NickH> I should be able to test it around this time or a little earlier tomorrow.

09:35 <NickH> Hmm, curious: would it work in a nested session?

09:36 <ifreund> NickH: only if the outer wayland session also supports touch input

09:36 <NickH> Ok.

09:36 <ifreund> it would probably be possible to write an emulator of sorts to spoof touch input for the nested session, I think I saw something like that for tablet tool testing

09:38 <NickH> Just wondering since that machine is my main work machine. Guess I can just switch to another TTY for testing and not lose my main session.

09:46 <ifreund> yeah, that's how I usually test things

09:47 <ifreund> my main session is almost always several commits behind master as I'm too lazy to restart it

09:49 <NickH> Just launched sway on another tty and checked the touch screen.

09:50 <NickH> Turns out that sway touch screen support seems to be totally out of whack when I had my external monitors configured.

09:52 <ifreund> might need to configure sway to map the touch input to the output with touchscreen support

09:53 <ifreund> haven't looked into this stuff in too much detail though yet

10:00 <talismanick> I have an HP Envy x360

10:00 <talismanick> I'd be willing to test it and report back

10:01 <NickH> From sway-input man page it seems that may be the case.

10:01 <talismanick> Ah. if it's likely to crash, that might be an issue....

10:01 <talismanick> hm, I think I'll do it

10:01 <talismanick> yolo

12:07 <xaltsc> Hey, is there any reason why river isn't upto date on void ? Given that ifreund is the maintainer, I'm a bit surprised.

12:10 <ifreund> xaltsc: void's LLVM packaging is extreemely behind -> Zig is out of date -> river is out of date

12:11 <ifreund> you can fairly easily grab a statically linked zig tarball from https://ziglang.org/download and build river from source though

12:11 <xaltsc> Yeah, that's what I'm doing, I tried to build it with xbps-src, but it didn't work...

12:13 <ifreund> you'd probably have to modify the zig template to use a binary tarball to do that

12:13 <ifreund> river requires zig 0.9.0 or 0.9.1, 0.8.0 won't work

12:15 <xaltsc> yup, the error I got was "no member named 'addOptions' in struct 'std.build.Builder'"

14:40 <fdnick> ok after trying lots of wayland tiling wm's, i decided to go with river for now. It's not the most feature loaded one, but seems tobe reasonable stable and simple. What i need to know now is: 1. how can i set the keyboard layout 2. how can i remap caps-lock to ctrl. Can anybody help me with that?

14:48 <nor[m]> fdnick: Start river with the XKB Variables set. Example: `XKB_DEFAULT_LAYOUT="de" XKB_DEFAULT_OPTIONS="caps:ctrl_modifier" river`

14:49 <fdnick> thanks

14:59 <fdnick> the layout works, the caps thing not

15:25 <fdnick> false alarm, works thanks

17:15 <wrl> is there any way to have an arbitrary window/surface "stick" the way that a bar does? or is that some internal protocol-level stuff

17:15 <wrl> ifreund: i think this is the right place this time ;)

17:18 <ifreund> wrl: do you mean like stay on top of all other windows? not really

17:18 <ifreund> you can set a window to be visible on all tags, but that won't affect how it is tiled/floats

17:21 <wrl> ifreund: i pretty much want it to work exactly like the bar does right now, in that it's "sticky" across tags and the windows lay out underneath it

17:28 <novakane> you can't, that depends of the layer option of zwlr_layer_surface, wich is set by the client

17:31 <ifreund> wrl: yeah, status bars and the like use a different protocol from "normal" windows called wlr-layer-shell

17:31 <ifreund> there's not really a way to make normal windows behave like that currently

17:42 <wrl> yeah i thought that was the case

17:42 <wrl> ifreund: but it could in theory be added

17:42 <wrl> ?

17:43 <ifreund> It's possible for a wayland compositor to implement yes, but not something I'm interested in supporting in river

17:44 <ifreund> clients where that behavior makes sense should use wlr-layer-shell

17:48 <wrl> yeah unfortunately this client is both closed-source and X11

17:48 <wrl> so that might exclude it permanently

18:02 <pigeon0> Can anyone help me figure out how to make waybar fully functional on riverwm?

18:02 <pigeon0> i never used waybar before

18:03 <pigeon0> and this is the first time I'm using a wayland wm

22:50 <NickH> pigeon0: https://github.com/Alexays/Waybar/wiki/Module:-River