waleee-cl has quit [Quit: Connection closed for inactivity]
leon-p has joined #river
<novakane[m]>
btw you removed the layout full in `river-layout-unstable-v1 ` or I missed it ?
<leon-p>
yes that one is gone now
<leon-p>
instead, river now treats all windows as floating when no layout is active
<novakane[m]>
ok thanks that's what I thought
yyp has joined #river
snakedye has joined #river
<snakedye>
ifreund there something special I have to do to get rivertile to work? I tried running it from the terminal inside river but except from having namespace conflicts, it didn't do anything
<leon-p>
it wont do anything until you tell river to use it
<ifreund>
snakedye: did you set a layout for your current output with riverctl set-option?
<snakedye>
ifreund how do i set a layout?
<ifreund>
set the "layout" optioin
<snakedye>
how do I tell river to use any layout generator?
<leon-p>
riverctl set-option -focused-output layout <name of layout>
<leon-p>
rivertile exposes four layouts named "tile-left", "tile-top", ...
<snakedye>
is that layout option somehow related to the namespace?
<leon-p>
the layout option of the output must match the namespace of the layout you want to use.
<snakedye>
does the fact you told to set the option implies it's already declared by default?
<leon-p>
it is
<snakedye>
so if i were to test my layout generator with the namespace "test", unless i set the option "layout" to "test", it won't send any events to it
<leon-p>
indeed
<snakedye>
Nice, rivertile works
<snakedye>
knowing this just saved me a lot of trouble
yyp has quit [Quit: now it's safe to turn off your computer]
snakedye has quit [Ping timeout: 240 seconds]
waleee-cl has joined #river
yyp has joined #river
<exception>
Hey, I have a question regarding multiple monitors: does river need some extra config because the second monitor can display windows and the mouse work but the input wil be given to the program on the main monitor
<exception>
*keyboard input
<leon-p>
you need to focus a window on the other output
<leon-p>
try `riverctl focus-output next`
<exception>
Ty
<skuzzymiglet>
workaround for freezing because of lack of damage tracking: `while true;do grim -g '0,0 1x1' -t ppm - >/dev/null;done`
<skuzzymiglet>
taking a screenshot seems to cause a redraw
<yyp>
But that doesn't make any sense, taking a screenshots only copies display buffer to where you need. Why could it even cause a redraw?
<yyp>
s/Why/How
<skuzzymiglet>
no idea :)
<ifreund>
that really smells like a wlroots bug
<yyp>
^
<skuzzymiglet>
so it's a bug that the screen redraws on screenshots?
<ifreund>
probably one that is rooted in the fact that river doesn't do damage tracking so it hits less-tested wlroots code paths
<yyp>
In any normal sense making a screenshot could cause a redraw. Maybe that's what should be done I guess
* yyp
shrugs
<ifreund>
skuzzymiglet: the bug is that the freezing happens in the first place
<yyp>
Wait
<yyp>
It might redraw before making a screenshot so you don't get some messed up garbage
<yyp>
Not sure where/if it happens though, I'm a bit afraid of reading wlroots code
<ifreund>
types/wlr_screencopy_v1.c
<ifreund>
wlroots code really isn't bad to read
<yyp>
I'm scared of reading any C code that is not written by me :)