notzmv has quit [Read error: Connection reset by peer]
notzmv has joined #river
bupa has joined #river
bupa has quit [Client Quit]
bupa has joined #river
bupa has quit [Quit: leaving]
notzmv- has joined #river
notzmv has quit [Ping timeout: 264 seconds]
eShaev9z_ has joined #river
eShaev9z has quit [Ping timeout: 264 seconds]
waleee has quit [Ping timeout: 264 seconds]
notzmv- has quit [Ping timeout: 252 seconds]
notzmv has joined #river
jao has quit [Ping timeout: 252 seconds]
Guest9 has joined #river
Guest9 has quit [Client Quit]
<scorpion2185[m]>
aisha: 0.2.1 will need zig 0.10 it was said
taupiqueur has joined #river
notzmv has quit [Ping timeout: 246 seconds]
duncaen has quit [Ping timeout: 264 seconds]
duncaen has joined #river
Szadek has joined #river
<leon-p>
I think focus-follow cursor with CSD views that set a geometry not matching the buffer size is still somewhat broken
<leon-p>
On a GTK4 application, If I enter with the mouse from the top or left, the view is only focused when the cursor is a decent chunck /inside/ the geometry, not on the edge
<leon-p>
on the right and bottom, it's even weirder: as soon as the cursor hits the surface, the cursor image is changed, but the view isn't focused. But if I am half-way between surface outer size edge outer geometry edge, then it get's focused
<leon-p>
so I think the box isn't aligned right
<leon-p>
it's off by about 5 pixels (scale 1), but unrelated to border-width
<leon-p>
man, I genuinely like CSD, but the tech behind it is cursed
<tleydxdy[m]>
leon-p: does the offset change when you move the window to a different place?
<leon-p>
huh, indeed it does
<tleydxdy[m]>
wth I thought I fixed that bug
<leon-p>
but only sometimes :/
<tleydxdy[m]>
I'll take a look when I wake up, what's the client?
<leon-p>
gnome-weather
<leon-p>
but can be reproduced with any GTK4 thing I have on this machine
<leon-p>
but not with the fancy new CSD mode of Snayk, so maybe it's a GTK bug
<leon-p>
(the geometry stuff recently inspired me to add a silly drop-shadow in CSD, because a) it's funny and b) it's probably good for testing things)
<tleydxdy[m]>
I was testing with a gtk4 client fwiw
<tleydxdy[m]>
transmission-gtk-git
<leon-p>
I recommend also testing with other CSD views, so that we don't accidentally over-correct for GTK
<leon-p>
river should be as agnostic to clients as possible
alexherbo2 has joined #river
<leon-p>
oh, GIMP let's you export things as arg8888 data stored in a c struct, which you can then memcpy into an shm buffer. Seems like I unlocked a few new hours of fun...
ayushnix has joined #river
ayushnix has quit [Changing host]
ayushnix has joined #river
ayushnix has quit [Remote host closed the connection]
<scorpion2185[m]>
when I hold the touchscreen on firefox it doesn't trigger the right click
<leon-p>
how firefox handles touch events has nothing to do with river
<scorpion2185[m]>
while not on river it works
<leon-p>
which non-river desktop do you tested it with?
waleee has joined #river
ayushnix has joined #river
<tleydxdy[m]>
leon-p I tried gnome-weather and it seem to work okay
<tleydxdy[m]>
can you give a little bit more detail on how to repro?
<leon-p>
open it, use csd filter, slowly move cursor onto the surface, observer focus change
<tleydxdy[m]>
nope still works correctly for me ;(
<leon-p>
hmm...
<tleydxdy[m]>
which focus follow are you using
<tleydxdy[m]>
normal or always?
<leon-p>
normal
<leon-p>
same with always btw
<tleydxdy[m]>
yeah idk then I tried different sizes/location
<tleydxdy[m]>
what's the border width?
<leon-p>
3
<leon-p>
but I tried changing it and that had no effect on the offset
<tleydxdy[m]>
yeah still works correctly on mine
<tleydxdy[m]>
maybe it's the layout generator? I'm just using rivertile
<leon-p>
should not have an effect on that
<tleydxdy[m]>
okay, maybe first, which commit are you on?
<leon-p>
v0.2.0 tag
<tleydxdy[m]>
hmm, I'm out of ideas :(
<scorpion2185[m]>
it's working only sxmo (dwm) so they must have added some support I guess
<leon-p>
another cause could be if the cursor that GTK loads has bad hotspot settings
<tleydxdy[m]>
you should see the cursor change before it gets focus fwiw
<leon-p>
scorpion2185[m]: touch works /completely/ different between X11 and Wayland
<leon-p>
on X11 the server pretends that touch is just a pointer input
<tleydxdy[m]>
it should get focus when the cursor enters the bordered part of the window
<leon-p>
while on Wayland the server just sends the touch events to the client
<leon-p>
meaning on X, firefox does not know that you are using a touchscreen while on Wayland it does
<scorpion2185[m]>
i guess it works on sxmo-sway too,it is not working on X11 generally but only on sxmo
<leon-p>
either way, rivre just sends the touch events along to the client
<leon-p>
hold-touch for context-click should be implemented by the client, not the server
<scorpion2185[m]>
could river send a right click event for long press automatically on all apps?
akumar[m] has joined #river
<leon-p>
That would be pointer emulation, which only makes sense if the client does not support raw touch events. While this one thing would probably work, in general the user experience would be a lot worse though (scrolling, gestures, etc..)
<leon-p>
basically: touch != mouse
alexherbo2 has quit [Remote host closed the connection]
<scorpion2185[m]>
does anyone have gestures working on river?
<tleydxdy[m]>
would be a nice fall back as long as the app have some way to tell that a pointer event is the same as the touch so it doesn't react twice for the same thing
<leon-p>
if you want to bind gestures to commands, you'll have to use aan external daemon for that since river has no gesture maps right now, but in-application gestures will work
<leon-p>
tleydxdy[m]: it's pointer-emulation XOR raw touch inputs
<leon-p>
the server can simply check if the client binds the necesarry interfaces
<scorpion2185[m]>
could river send a touch event that correspond to the right click for long press then?
<tleydxdy[m]>
I see
jao has joined #river
<leon-p>
scorpion2185[m]: no, because while a mouse click has different buttons, a touch is just a touch. Interpreting that is up to the application.
taupiqueur has quit [Ping timeout: 246 seconds]
alexherbo2 has joined #river
taupiqueur has joined #river
alexherbo2 has quit [Ping timeout: 260 seconds]
taupiqueur has quit [Ping timeout: 255 seconds]
<scorpion2185[m]>
how do you turn off the screen in a way that pressing a key turn it on again?
<tleydxdy[m]>
use acpi, I think
<tleydxdy[m]>
mine does it automatically after a timeout
alexherbo2 has joined #river
taupiqueur has joined #river
<leon-p>
swayidle to detect idleness and keypresses, pair with wlopm to turn off / on screen
<leon-p>
scorpion2185[m]: ^
taupiqueur has quit [Ping timeout: 260 seconds]
alexherbo2 has quit [Ping timeout: 260 seconds]
taupiqueur has joined #river
<scorpion2185[m]>
can you use wlr-randr instead of wlopm?
waleee has quit [Ping timeout: 265 seconds]
taupiqueur has quit [Ping timeout: 252 seconds]
<leon-p>
last time I checked, wlr-randr did not support the output power management protocol
alexherbo2 has joined #river
<leon-p>
that's btw the reason I wrote wlopm in the first place
taupiqueur has joined #river
<scorpion2185[m]>
don't you need to simply turn the screen off?not suspending
<scorpion2185[m]>
the good old lxsession-logout is working fine to suspend
<leon-p>
depends what you want, disable the output, meaning it literally does not exist anymore and all windows are evacuated, or simply turning off the screen.
<leon-p>
wlopm does the second thing
taupiqueur has quit [Ping timeout: 248 seconds]
alexherbo2 has quit [Ping timeout: 260 seconds]
<scorpion2185[m]>
ah I saw output off in the wlr-randr and I thought that it was that
<scorpion2185[m]>
is that the first thing?
<leon-p>
it just turns the display off, although the terminology is certainly not helping to avoid confusion.
<codedotjs[m]>
But de and en combined don't seem to work. I changed it to de,de and everything is fine. Is it really possible to use two different layouts as default?
<codedotjs[m]>
> As you already know from river(1), the keyboard layout is configured by setting the XKB_DEFAULT_LAYOUT env var before starting river (setting it in your init will not work). If you want to use multiple keyboard layouts, you can write them all into the env var, comma separated:
<leon-p>
codedotjs[m]: it is possible, howver I think "en" isn't a valid layout on some distros
<leon-p>
btw, river now has a command for setting the layout, so you don't need the env var anymore
<leon-p>
probably should update the wiki
<leon-p>
you can use `xkbcli list` to get a list of all layouts and variants, but it's a bit unwieldy to get through
<leon-p>
so instead of "en" you probably want to use "us" or "uk"
n0r has left #river [#river]
Guest3 has quit [Ping timeout: 260 seconds]
Guest96 has joined #river
<Guest96>
Hello. Where can I find an example of config for workspace manipulation? For example, how can I change current workspace.
<leon-p>
checkout the directory called example/ in the repo
<leon-p>
it has an example init in it
<Guest96>
It is a difficult example to be honest. I don't know what "view", "layout stack", and "output" are.
<Guest96>
And I didn't find "workspace" there.
<leon-p>
view is wayland-speak for what you probably call window
<leon-p>
output is the logical object backing each physical screen (and virtual screens, should you have them)
<leon-p>
the stack is the data structure the views are stored in. literally just a list.
<leon-p>
also river does not have workspaces, it has tags.
<leon-p>
instead of having multiple worspaces each with their own list of windows, there is a single list of windows which all have a bitset. the output (screen) also has a bitset. they are AND'd. if (output.tags AND window.tags) is greater than 0, the window is displayed, otherwise it remains hidden