<Anderson-D>
Just checked out `hide-cursor` & `map -layout N` commands and it's totally awesome! River has been my daily driver for the past few months and I absolutely love it
<Anderson-D>
I have one issue though, I'm using a keyb with a rotary encoder which is mapped to mouse scroll wheel. Every time I use it, my cursor reappears since river thinks I'm using my mouse. Is it possible to somehow prevent it from appearing unless mouse was actually moved/clicked?
<Anderson-D>
I was thinking about two options: 1) adding one more enum to `HideCursorWhenTypingMode` or 2) adding filtering by device to call `unhide()` conditionally
<Anderson-D>
Thoughts?
Guest12 has joined #river
<Guest12>
Hello, is there a way to have tabs like in sway ?
snakedye_real has quit [Quit: snakedye_real]
<ifreund>
Guest12: nope, no tabs
<ifreund>
Anderson-D: If your rotary encoder is exposed to river as a mouse scroll wheel then it will be reported to the wayland client that currently has pointer focus as part of the wl_pointer interface
<ifreund>
I think unhiding the cursor makes sense in this case as the cursor's location determines which client will recieve the events
<Guest12>
ifreund: is there than maybe a way to swap apps from different tags, into the same position
<Guest12>
?
<Guest12>
Most of the time i have split my screen into four parts, an easy way to replace one of the apps would be great
<ifreund>
You can kind of hack it by seting the views you don't want to swap to be on e.g. tags 1, 2, and 3
<ifreund>
then for the 3 views you want to swap between set them each to a single tag in that set (1, 2, or 3)
<Guest12>
i can set a tag to a view?
<ifreund>
then switch focus between tags 1, 2, and 3 to effectively swap out 1 view
<ifreund>
this isn't very ergonomic though and doesn't guarentee that the position of the "replaced" view in the stack will be the same
<ifreund>
Guest12: all the tag related commands are document in the TAG MANAGEMENT section of the riverctl man page
<Guest12>
ok, i have to check them out
<Guest12>
can you have multiple views per output ?
<nor[m]>
Vew = Window. Do you mean "multiple tags"? That is possible aswell.
<nor[m]>
s/vew/view
<Guest12>
Ok
<ifreund>
I should really s/view/window/ in all user-facing river docs/commands
<ifreund>
I don't think it's worth the breaking change though at this point
<nor[m]>
Where does the view terminology come from? Is it a wayland protocol thing?
<Guest12>
maybe just at a definition for view?
notzmv has joined #river
<ifreund>
nor[m]: it originated in weston's source code a long time ago because they were planning on allowing multiple different views of the same client at the same time
<ifreund>
It kinda got picked up by wlroots and sway from there, and then I just cargo culted it into river's code in the early days
<Shinyzenith[m]>
searched for the libc 64 package it wants, found nothing :(
<ifreund>
weird, wouldn't expect arch's valgrind packaging to be messed up
<Shinyzenith[m]>
¯_(ツ)_/¯
<Shinyzenith[m]>
what boggles my mind is that
<Shinyzenith[m]>
self.field = expr
<Shinyzenith[m]>
self.* = .{field = expr}
<Shinyzenith[m]>
segfaults over
<Shinyzenith[m]>
like why
<Shinyzenith[m]>
Initially I thought my patch might've been too big to debug so I simply just tried changing the style around and found that self.field = expr breaks it
<ifreund>
I doubt that's the actual cause, you've likely got a memory error somewhere else that only blows up when when the stack usage changes due to that change or something
<ifreund>
really I'd recommend figuring out how to get valgrind running on your distro, try your distro's IRC channel
<Shinyzenith[m]>
Can gdb suffice?
<Shinyzenith[m]>
because I've already tried valgrind for weeks now
<Shinyzenith[m]>
and failed over and over again 😆
<ifreund>
you can try gdb, but it can't tell you as much as valgrind can