fitrh has quit [Remote host closed the connection]
fitrh has joined #river
<larstiq>
kaisan1: cheers, some interesting ideas in there
fitrh has quit [Ping timeout: 256 seconds]
fitrh has joined #river
fitrh has quit [Ping timeout: 256 seconds]
fitrh has joined #river
ninewise has quit [Remote host closed the connection]
ninewise has joined #river
fitrh has quit [Remote host closed the connection]
fitrh has joined #river
fitrh has quit [Ping timeout: 256 seconds]
fitrh has joined #river
leopoldek has quit [Remote host closed the connection]
Guest76 has joined #river
<Guest76>
how can I set the newly spawn view/window to be focused BUT NOT in the main count !?
Guest76 has quit [Client Quit]
<fitrh>
Guest76: I think setting `default-attach-mode` to 'bottom' or 'below' is what you want
Hawk55 has joined #river
Hawk55 has quit [Quit: Client closed]
Hawk34 has joined #river
fitrh has quit [Ping timeout: 256 seconds]
<Hawk34>
Hi, I'm not super knowledgeable on this, but I'm hoping someone can point me in the right direction. I have a new QMK keyboard and I'm trying to map the media keys, but they don't seem to trigger the XF86.... keysyms.
<Hawk34>
I can see a KEY_VOLUMEUP event using libinput debug-events, but wev gives nothing when pressing the button. I did some searching, but I have no clue how to get these mapped in river
aktina has joined #river
aryak has joined #river
<ifreund>
Hawk34: hmm, any chance they are already mapped? the example init file maps them I believe
<ifreund>
if you've copied from that you may have existing, non-functional mappings
<Hawk34>
Well yes, I have them mapped, but they're not working since the keyboard events don't seem to match with what XKB uses. I'm just unsure how I fix these non-functional mappings
switchy has quit [Ping timeout: 244 seconds]
switchy has joined #river
<ifreund>
Hawk34: if you have them mapped then the key events will be eaten by river and not shown by wev
<ifreund>
are you 100% sure the mapped command works?
<ifreund>
you could also unmap the keys to make the events show up in wev as a test
<Hawk34>
Oh you are correct, thats very odd
<Hawk34>
I unmapped them and wev sees them
<Hawk34>
And it seems I am dumb, as my command was indeed not working. Didn't have the tool installed ;(
<Hawk34>
ifreund thanks a lot for the second pair of eyes. Sometimes you're just staring beyond the actual problem :D
mtm has quit [Ping timeout: 260 seconds]
<ifreund>
no problem!
mtm has joined #river
Hawk34 has quit [Quit: Client closed]
fitrh has joined #river
leopoldek has joined #river
fitrh has quit [Ping timeout: 256 seconds]
fitrh has joined #river
fitrh has quit [Remote host closed the connection]
sm2222 has joined #river
sm222 has joined #river
<sm222>
potentially dumb question, when am i meant to riverctl spawn things, and when should i just exec them? Looking at different dotfiles I see some people that just spawn everything where as others use an autostart script of some sort.
<leon-p>
matter of taste really
<leon-p>
spawn is just a double-fork exec
<leon-p>
and if you use your shells job control to spawn things in the background instead, maybe process relationships may end up slightly different
<leon-p>
but it's really quite irrelevant
<sm222>
interesting, thank you very much :)
<leon-p>
note that exec in your init script may be a bit different though
<leon-p>
exec in shell replaces the current process with a new one. In case of init, the new process will end up as a direct child of river and river will end it on exit
<leon-p>
there won't be a difference for most programs
<sm222>
yeah makes sense, I don't think at the moment I'm using exec at all in my init
<leon-p>
however it's a bit of a foot-gun apparently, since we've seen a lot of people not knowing exec in shell replaces the process and therefore subsequent lines in the init will never be reached
<sm222>
I may or may not have done that by accident not long ago
przmk has joined #river
przmk has quit [Changing host]
przmk has joined #river
sm2222 has quit [Remote host closed the connection]
przmk has quit [Remote host closed the connection]
Den4ikRus has quit [Ping timeout: 252 seconds]
<ifreund>
in retrospect, we could have made spawn only vaild as an argument of map
<ifreund>
it would avoid this confusion
sm222 has quit [Ping timeout: 252 seconds]
<leon-p>
we can drop it with the WM protocol, so that river itself only spawns the WM process and nothing else
<The_Buhs>
Is it river or wayland or my configuration that's the reason I can't push-to-talk in discord unless I have like specific apps active?
<The_Buhs>
Like it doesn't work unless I'm on Steam or Steam games and probably some other stuff. But If I'm on a browser or a terminal or even Discord itself, PTT just doesn't work.
<leon-p>
because there is no mechanism in wayland to have a client-side global keybind
<leon-p>
if you have PTT, it's running through XWayland
<leon-p>
and as such will only work in XWayland windows
<leon-p>
I think there is a portal for global keybinds, but I would be surprised if anything actually supported it
<leon-p>
the recommended workaround is to find out if you can trigger mute/unmute via IPC and bind those commands to keyys via rivers keybinding facilities