00:29 <Guest85> So i’m encountering this error under a fresh arch install

00:30 <Guest85> when i run sudo river, it’s saying something about an IME_DIR being invalid

00:30 <Guest85> and just running river normally says it can’t connect to a socket due to insufficient permissions

00:42 <Guest52> i seem to be getting a runtime dir error for xdg

00:43 <leon-p> no, no sudo

00:43 <leon-p> don't run river as root

00:44 <leon-p> if sway feels slow, river likely will too, since they do basically the same w.r.t. rendering

00:44 <leon-p> probably software rendering. make sure you have a supported graphics chip

01:38 <Guest52> i do have a integrated gpu

01:39 <Guest52> i’ve used i3wm and it feels decent so i wanted to try river

01:39 <Guest52> i just called it quits for today. I was having a lot of issues on arch and didn’t know why

01:39 <Guest52> something related to IRQ #9

01:41 <Guest52> also on arch linux just installing river and running it seems to not work

01:41 <Guest52> at least for me

04:24 <ayushnix> not sure which username to tag but make sure you've not set max_render_time too low

04:25 <ayushnix> otherwise sway will start dropping frames

06:44 <amuse> hey! i'm the person who was talking about river and everything before

06:44 <amuse> so i was doing a bit more work and i got river to work under arch

06:44 <amuse> i think i had to mess with my user's group (needed to add myself to seatd and start the service)

06:45 <amuse> one really weird thing that happened is none of my keybindings EXCEPT exit river was working

06:45 <amuse> i made sure foot was installed and startable

06:45 <amuse> kept pressing keybinds

06:45 <amuse> but nothing worked

06:46 <amuse> nothing other than super + shift + e

06:47 <amuse> so i could only really enter and exit river

06:47 <amuse> i switched back to windows, but I can try replicating it in a few days

07:46 <NickH> What ~/.config/river/init did you use?

10:10 <larry53> Hi, I am using river and having a great time using it, but I am facing a little problem using it

10:10 <larry53> I have set the following options

10:10 <larry53> riverctl map normal Super+Shift Space spawn bemenu-run

10:10 <larry53> And it launches bemenu just fine, but it doesn't respect the environment variables I have set.

10:10 <larry53> I am using the fish shell and currently I am using this environment variable to configure bemenu

10:10 <larry53> set -gx BEMENU_OPTS "-b --fn 'Iosevka Nerd Font Mono 15' -H 40 --prompt Launch --tb #225877 --tf #ffffff --hb #225877 --hf #ffffff"

10:10 <larry53> Launching bemenu-run from the terminal emulator works just fine,while respecting the environment variables but launching using riverctl keybindings everything just reverts back to default.

10:10 <larry53> How can I fix this issue?

10:10 <larry53> Thank you for your time

10:12 <ifreund> larry53: set the environment variables before launching river

10:17 <larry53> Hi ifreund, thank you. That solved my issue.

13:23 <lordmzte> ifreund: regarding your comment on my PR: the difference between `MapToOutput.output_name` being null and `map-to-output` being null is that, in the former case, the input device is explicitly mapped to null whereas in the latter case, nothing will be done at all. If we were to eliminate the former case as you suggested, we'd have to add more special-casing here if a mapped input device should be

13:23 <lordmzte> unmapped from an output, either by the user setting it to `disabled` or the output being removed.

13:25 <ifreund> lordmzte: what's the differenc between an input device being mapped to NULL and an input device never having been mapped to anything?

13:25 <ifreund> I'm pretty sure there is none

13:26 <ifreund> I see no problem with mapping all input devices to NULL by default if it makes the code cleaner

13:27 <lordmzte> Yes, but we must explicitly map an input device to null in the two cases I mentioned. If the user sets the setting to disabled or the output is disconnected, we need to call wlr_cursor_map_input_to_output(..., null). Currently, only settings that are non-null in InputConfig have their apply run.

13:28 <lordmzte> I can add a special case here if you'd like to always call apply, if you'd prefer.

13:28 <ifreund> lordmzte: then make InputConfig.@"map-to-output" non nullable?

13:29 <lordmzte> Ah I see, I didn't even think about that as all the other settings were nullable :D Will do!

13:29 <ifreund> As I've said, InputConfig needs a refactor to separate out the libinput config options

13:29 <ifreund> all the other settings have different semantics since the default are determined by libinput version/hardware quirks/whatever, not by river

13:30 <lordmzte> yup, but that should be left to another PR.

13:30 <ifreund> yeah, just explaining why this new option is different :)

13:38 <amuse> @NickH I was using the default from from the github

13:39 <ifreund> to be pedantic, there is no default init file, only an example

13:39 <amuse> oh yeah the example file haha

13:40 <ifreund> also note that the example from river's master branch may not match the river version you have installed from your distro package manager

13:40 <amuse> i can *try* reproducing again

13:41 <amuse> yeah, i believe i installed the 0.2.x init example file

13:42 <amuse> but I don't think that matters, as i copied the init file from /usr/share/river/example/init like the archwiki said

13:42 <ifreund> yeah, then that's the version installed by your package mananger

13:42 <amuse> hm

13:43 <ifreund> there might be something in the river logs related to your issue, you could try redirecting river's stderr to a file and reading that

13:43 <amuse> I believe I tried that, there was no unusual errors that popped up

13:44 <ifreund> do you have any funky keyboard layout stuff going on?

13:44 <amuse> nope. I know it's not the keyboard cause only the exit river keybind worked

13:44 <amuse> nothing else

13:44 <amuse> i made sure the MOD key was correct, foot was correctly installed

13:46 <ifreund> you could try starting river, switching to a different tty, and running `WAYLAND_DISPLAY=wayland-1 foot` or whatever

13:46 <ifreund> and then run riverctl commands from that foot instance directly

13:47 <ifreund> I must admit this doesn't really sound like a river bug but rather a configuration error though

13:47 <lordmzte> What is your expert opinion on this code I came up with to handle both optional and non-optional fields in InputConfig? https://paste.rs/lSAIi

13:48 <adamcstephens> I think I may have been premature in my celebration of frames being fixed. electron apps are still confused.

13:48 <amuse> would it be related to the way i installed arch? i didn't fully manually install, I just used "archinstall" and clicked the "minimal installation" option

13:49 <amuse> that would really be a long shot

13:50 <amuse> but I will try again soon! thanks for your help

13:54 <ifreund> adamcstephens: if you don't mind, opening a new issue with a WAYLAND_DEBUG=1 log of the program with visible window border glitches would be great

13:55 <ifreund> lordmzte: maybe just special case the one field that's not optional?

13:55 <lordmzte> well honestly that would boil down to even more code here :P

13:55 <ifreund> or just do whatever works, codereview really belongs on github

13:56 <lordmzte> yes sorry :)

13:56 <lordmzte> On a separate note, I've also been getting some weirdness with window borders, but it's been to random for me to turn it into an issue.

13:57 <ifreund> Theoretically it should only happen with buggy clients now

13:57 <lordmzte> Happens with a client i wrote so probably yes xD

14:00 <ifreund> in any case, a new issue with a WAYLAND_DEBUG=1 log of the client for me to look at would be helpful

14:01 <ifreund> we could be more accomodating to buggy clients here and just log shame messages and fix their mistake

14:01 <ifreund> such clients will never be frame perfect though and that's their fault

14:01 <ifreund> this issue has more details: https://github.com/riverwm/river/issues/807

14:02 <lordmzte> My client only creates a window for clipboard access and then immediately destroys it again

14:02 <lordmzte> (I realize there was some protocol for getting clipboard access without a window, but that's not yet implemented.)

14:22 <lordmzte> Alright, we should be ready for the next round of review.

14:41 <lordmzte> I see we're 3 issues away from reaching #1000!

14:44 <lordmzte> 4*

16:38 <The_Buhs> Why does `riverctl map normal Alt+Control Print spawn "grim -g - \"$(slurp)\" | wl-copy"` not work?

16:38 <The_Buhs> by not work, I mean, when I make the bind it spawns the command immediately for some reason, and then when I try use it nothing happens

16:59 <leon-p> The_Buhs: shell escaping fun

16:59 <The_Buhs> 😃

16:59 <leon-p> when you call the command, your shell immediately sees the $(slurp), evaluates that, places the returned string into the rest of the command and then calls riverctl

17:00 <The_Buhs> ah that makes sense

17:01 <amuse> ah, polkit seems to be an optional dependency for river on arch

17:01 <amuse> and i forgot to install it

17:01 <amuse> wow

17:01 <amuse> i think my issues are mostly solved now

17:02 <amuse> are yall using a greeter/dm for river?

17:04 <leon-p> I use greetd, but configured it to automatically start river. I already habe a LUKS prompt, no need for a second password prompt

17:04 <lordmzte> I have my own "greeter"

17:04 <lordmzte> Which isn't technically a greeter, it's the login shell.

17:13 <amuse> so you have river on autostart?

17:13 <amuse> like once you log into tty

17:36 <leon-p> no, I skip the TTY login. as I said, I already have a LUKS password prompt, why waste time entering another password?