<wrl>
ok so i have a layout that has two windows maximised, with one on top of the other
<wrl>
i run "slurp | grim -g -"
<wrl>
when i click on the window to start drawing the capture rect, river rearranges the windows
<wrl>
a) why is this happening
<wrl>
b) can this *not* happen
<wrl>
(and when i say "rearranges the windows", i mean "switches the window being displayed")
elshize has quit [Ping timeout: 252 seconds]
notzmv has joined #river
talismanick has joined #river
talismanick has quit [Remote host closed the connection]
jao has quit [Remote host closed the connection]
jao has joined #river
StopNGo has joined #river
elshize has joined #river
eShaev9z has joined #river
eShaev9z_ has quit [Ping timeout: 264 seconds]
elshize has quit [Ping timeout: 260 seconds]
waleee has quit [Ping timeout: 264 seconds]
StopNGo has quit [Ping timeout: 260 seconds]
snakedye has quit [Ping timeout: 246 seconds]
jao has quit [Ping timeout: 252 seconds]
janq0 has joined #river
Ordoviz has joined #river
<janq0>
Hello again, I'm not sure why I wasn't getting this error earlier but now I'm getting a `error: failed to run init executable $HOME/.config/river/init: FileNotFound`. I double checked that `$HOME/.config/river/init` exists and `$HOME` is set to the correct directory. Does anyone have any ideas?
<plumeus>
The obvious case is if the `init` file isn't set as an executible.
<plumeus>
I recall seeing another person have incorrect group:owner permissions, but hopefully that's not the case
<janq0>
I did do `chmod +x` on it. I was checking the source code and that ParmissionDenied has it's own dedicated error message so I don't think that's the issue.
<plumeus>
btw, have you tried to run the init script to see if it works?
<janq0>
yup
<plumeus>
interesting
<janq0>
I'm using `river -c $HOME/.config/init` to launch and it's working
<plumeus>
Oh, and just in case it might help for someone to diagnose later, I think it would be nice if you could say whether you use the latest commit or not.
<plumeus>
oh, and I guess check if `$XDG_CONFIG_HOME` is set to something other than `$HOME/.config`, which I would doubt.
<janq0>
Nah I checked
<janq0>
Does `river-git` from the AUR have the latest commit? I'm using `river` (AUR) right now
<plumeus>
have you tried directly invoking the script with `./init`?
<plumeus>
I just tried `river -c $HOME/.config/river/test` and it started River even though I didn't give it proper permissions
Ordoviz has quit [Ping timeout: 260 seconds]
<janq0>
Did it execute the test script
<plumeus>
yep
<janq0>
Wait what do you mean by permissions?
<plumeus>
I just mostly copied my `init` script and changed file permissions
<plumeus>
File permissions. For example, if you do `ls -l init`, it should show `-rwxr-xr-x`. But you said you already did chmod.
<janq0>
Yeah I have this exact code
<plumeus>
In my case, I did `chmod 644` to the test script.
<plumeus>
welp, weird
<janq0>
Should `$HOME` be `/home/user` or `/home/user/`
<plumeus>
It doesn't need a closing slash, so the former is fine
<plumeus>
Since you're supposed to do `$HOME/.config` for example, not `$HOME.config`
<janq0>
ah True
<janq0>
Well, I have no more ideas then
<plumeus>
Capitalising "true" like a true Haskell user /s
<janq0>
or python :D
<plumeus>
welp, if your XDG + HOME + the rest of paths are correct and the file permissions are correct and `river -c` works... yeah, I'm out of ideas myself. Try using a different version?
<plumeus>
does `river -version` tell you the version?
<plumeus>
err, commit
<janq0>
Only version
<janq0>
let me try river-git
<plumeus>
Oh, you weren't using -git, misread. So, must be on 0.1.3 or something
<janq0>
yes
<janq0>
Oh wait I had no idea that the latest git version is 0.2 already
<plumeus>
0.2-dev
<plumeus>
so, you're still fine for using 0.1.3 if you don't need newer features
<plumeus>
But nothing that would cause a "FileNotFound" error.
<janq0>
I just tried it on 0.2 and I'm getting the same error
<plumeus>
fuuuuun
<janq0>
Unless you have any more ideas I think I'll just stick to `river -c ~/.config/river/init`
<plumeus>
just to triple check, what is the output of typing `$HOME/.config/river/init` into the shell?
<plumeus>
like, executing the init file on a tty without `river -c`
<plumeus>
Because the only other thing I can imagine is like, you did something like `sudo cp` for some reason and the group permission for the file became root or something weird... which you probably would have noticed but I'm out of ideas.
Ordoviz has joined #river
<janq0>
Is it possible to kill river from another session? All my sessions are stuck with river that I can't quit lol
<janq0>
except the one that I'm on right now
<plumeus>
hmm, you can probably do some `ps` or `pgrep` stuff to find out which rivers you want to kill and then use `kill`
<plumeus>
Or do Shift + Mod + E if you kept the default keybinding and that works
<plumeus>
btw, you can start river inside river
<plumeus>
because Wayland, yaaay
<janq0>
If I run init from a tty i get `error: The Wayland server does not support river-control-unstable-v1.
<janq0>
Do your versions of river and riverctl match?`
<plumeus>
in my case, yes, lemme check a bit further though.
<plumeus>
oh wait, no, that's expected
<plumeus>
because you're running `riverctl` without a Wayland server
<janq0>
yes
<plumeus>
so it is indeed a proper executable in the right path
<plumeus>
weird... yeah, just use `-c` and maybe ifreund or someone can help you list the details necessary to open an issue later or something
<janq0>
Thanks for for your time plumeus
<plumeus>
welp, I feel defeated, ha
<janq0>
It's ok
janq0 has quit [Quit: Client closed]
janq0 has joined #river
<dnkl>
"strace river &> /tmp/river.log". then check river.log and see which files it's trying to access
snakedye has joined #river
StopNGo has joined #river
<tiosgz>
wrl: river renders views in the stack order and only puts the focused one on top
<wrl>
tiosgz: ok so how do i have it not do that
<tiosgz>
starting slurp unfocuses it, so everything is in stack order
<wrl>
yes i understand
<tiosgz>
so you can just reorder the views
<wrl>
how do i have it not do that
<wrl>
how do i reorder the views
<wrl>
and why is it not already doing that when i move through them
<tiosgz>
with mod+shift+j/k or mod+enter with the default config
<tiosgz>
it would be pretty weird to focus a window and have it automatically move somewhere else
<wrl>
can i make river just... not do this "raise the focused window to the top" thing
<wrl>
whether i'm dealing with floating windows or non-floating, this behaviour becomes infuriating
<tiosgz>
then you would only see the focused window when it's on top of the stack
<wrl>
river is the *only* wm i've ever used that does this
<tiosgz>
but i think you can make river zoom the view when you focus it
<wrl>
literally every other dynamically tiling wm i've used doesn't do this
<tiosgz>
i mean something like (beware: not checking if it's valid) "riverctl map normal Super J spawn 'riverctl focus-view next; riverctl zoom'"
<leon-p>
janq0, plumeus: to quit river when not "inside" the session, you can manually set the WAYLAND_DISPLAY env var and call riverctl. Rivers IPC is implemented as a custom Wayland protocol extension.
<leon-p>
We could probably improve the documentation and error messages here a bit though
Ordoviz has quit [Ping timeout: 265 seconds]
<janq0>
dnkl There's this: `access("$HOME/.config/river/init", X_OK) = -1 ENOENT (No such file or directory)` but the whole log is 41k lines
<tiosgz>
you also wrote that you use "river -c $HOME/.config/init" without problems...
<janq0>
Yes
<leon-p>
janq0: How do you set XDG_CONFIG_HOME and where?
<tiosgz>
if that's what you actually use, then you're missing the river/ part
<leon-p>
beause there shouldn't be a "$HOME" in the access syscall. That means you probably tried setting the variable in a way that prevents the expansion of $HOME
<janq0>
I had to manually append "XDG_CONFIG_HOME=$HOME/.config" to /etc/environment
<leon-p>
don't do that
<leon-p>
use .profile
<leon-p>
the $HOME part does not expand when you place it in /etc/environment
<janq0>
Oh
<janq0>
Well
Ordoviz has joined #river
janq0 has quit [Quit: Client closed]
janq0 has joined #river
<janq0>
Thanks for your healp leon-p! Removing the line from `/etc/environment` and adding `export XDG_CONFIG_HOME="$HOME/.config` to `~/.profile` fixed my problem.
<plumeus>
btw, is this on latest commit? I feel like I had an issue like this with XWayland on 0.1.3
<wrl>
plumeus: it's a decent media hosting site :P
<wrl>
and no, this is 0.1.3
<wrl>
i could try updating
<wrl>
but this definitely happens with native wayland surfaces too
<plumeus>
oh
<plumeus>
Do try, there were a few XWayland-related commits that fixed similar issues for me.
<wrl>
well
<wrl>
it's the "focused window comes to front" behaviour
<wrl>
i want it to not happen, i want it to be configurable
<wrl>
it happens when i focus out of a window
<leon-p>
it's not configurable, it's not a simple change to make
<wrl>
i continue making the case that it should be because it is enormously frustrating
<wrl>
the only thing contrived about this example was the image i used to demonstrate it
<leon-p>
window ordering is a known issue already
<plumeus>
do you have `riverctl focus-follows-cursor` disabled?
<wrl>
well so i want the *keyboard* focus to follow the cursor
<wrl>
but i don't want the focused window to raise above everything else
<leon-p>
since there is no way to manually raise or lower windows, raising the focused window is necessary
<leon-p>
(stacking order is equal to layout order)
<wrl>
dwm behaviour is raise window when moving with the cursor
<wrl>
which would be a relatively simple change to make
<leon-p>
yes, we are aware other software does things differently
<plumeus>
"relatively simple change" is an assumption
<leon-p>
no, it would not. Because a) that is not actually what dwm is doing and b) don't make assumptions about the complexity of features without having spend a minute or two in rivers codebase
<wrl>
in Cursor.zig enterMode in the .move case it seemed possible that the view being moved could be removed from the view stack and then re-inserted at the top of it
<leon-p>
That just implicit manual raising
<leon-p>
which btw would not work for tiled layout that feature overlapping windows
<leon-p>
what you really want is decoupling stacking order and layout order. Something like that has been discussed before, but we did not reach any conclusion, mostly due to a lack of interest. If you really care about it, open an issue.
Ordoviz has quit [Ping timeout: 252 seconds]
Ordoviz has joined #river
Guest27 has joined #river
Guest27 has quit [Client Quit]
Guest52 has joined #river
Guest52 has quit [Client Quit]
StopNGo has quit [Ping timeout: 264 seconds]
Ordoviz has quit [Ping timeout: 260 seconds]
jao has joined #river
Ordoviz has joined #river
Ordoviz has quit [Ping timeout: 246 seconds]
aryak has quit [Read error: Connection reset by peer]
aryak has joined #river
waleee has quit [Ping timeout: 246 seconds]
janq0 has quit [Quit: Client closed]
Ordoviz has joined #river
n0r[m] has quit [Quit: You have been kicked for being idle]