ChanServ changed the topic of #river to: river - a dynamic tiling Wayland compositor || https://codeberg.org/river/river || channel logs: https://libera.irclog.whitequark.org/river/
dumbmf has quit [Ping timeout: 276 seconds]
schneid3306 has quit [Quit: schneid3306]
dumbmf has joined #river
sentry has joined #river
Snetry has quit [Ping timeout: 252 seconds]
palanix has quit [Ping timeout: 265 seconds]
palanix_ has joined #river
palanix_ is now known as palanix
alexandersix has joined #river
<alexandersix> Hey folks, I'm new to Wayland in general, but specifically tiling Wayland compositors, but I've used AwesomeWM for a long time prior to making the switch over to River. I was curious if any of you knew of the right way to set mouse pointer sensitivity / speed within River. I know Sway has a setting for that, but is there some way to handle that in
<alexandersix> River?
krei-se- has joined #river
alexandersix has quit [Ping timeout: 240 seconds]
aktina has quit [Ping timeout: 260 seconds]
<NickH> Look for accel-profile and pointer-accel in the riverctl man page
aktina has joined #river
elshize has quit [Ping timeout: 248 seconds]
belanthor has joined #river
Guest16 has joined #river
Guest16 has quit [Client Quit]
Keeto has joined #river
Keeto has quit [Ping timeout: 252 seconds]
Keeto has joined #river
pixavi has joined #river
belanthor has quit [Ping timeout: 276 seconds]
belanthor has joined #river
belanthor has quit [Ping timeout: 248 seconds]
Keeto has quit [Ping timeout: 248 seconds]
pixavi has quit [Ping timeout: 276 seconds]
pixavi has joined #river
Keeto has joined #river
pixavi has quit [Ping timeout: 252 seconds]
pixavi has joined #river
pixavi has quit [Ping timeout: 252 seconds]
kraem has quit [Remote host closed the connection]
kraem has joined #river
elshize has joined #river
pixavi has joined #river
belanthor has joined #river
<leon-p> ifreund: in zig-pixman, create_linear_gradient takes multiple gradient_stop_t's, shouldn't the pointer type by [*]GradientStop ?
<leon-p> And would you accept eventually accept a patch to add null checks to return zig errors on failure?
glenneth1 has joined #river
<leon-p> and how about binding int_to_fixed and double_to_fixed?
glenneth has quit [Ping timeout: 244 seconds]
belanthor has quit [Quit: Leaving]
<leon-p> oh, the pixman fixnum converters are macros
Guest86 has joined #river
Guest86 has quit [Quit: Client closed]
pixavi has quit [Ping timeout: 252 seconds]
pixavi has joined #river
elshize has quit [Ping timeout: 252 seconds]
Keeto has quit [Quit: Lost terminal]
<ifreund> leon-p: river barely uses any of the pixman API surface so I'm not surprised there are missing bits/rough edges
<ifreund> in any case, patches are welcome :)
pixavi has quit [Quit: pixavi]
pixavi has joined #river
pixavi has quit [Remote host closed the connection]
br0qn has joined #river
<aelius> Is there a way to map-pointer to just a modifier without a button?
<aelius> Or in general- modifiers can be set to none, but can buttons be set to none?
ccha has quit [Quit: WeeChat 4.6.0]
ccha has joined #river
br0qn has quit [Remote host closed the connection]
elshize has joined #river
Keeto has joined #river
elshize has quit [Ping timeout: 245 seconds]
catman has joined #river
<leon-p> ifreund: how does decoration surface offset interact with scaled decoration buffers? Is the offset in scaled or unscaled coords?
<leon-p> probably unscaled
br0qn has joined #river
Keeto has quit [Remote host closed the connection]
br0qn_ has joined #river
br0qn has quit [Ping timeout: 268 seconds]
br0qn_ has quit [Client Quit]
graves has quit [Ping timeout: 252 seconds]
<leon-p> ok my window decorations are already resizing but I don't think I have implemented that actually... spooky
Nickli has quit [Ping timeout: 268 seconds]
elshize has joined #river
Nickli has joined #river
<leon-p> best thing: it's incredibly cheap to render, since the texture is only drawn once and then with viewporter and 8 surfaces "stretched" around each window
<aelius> hrm, trying to use creek, but it's giving me errors about scale not being divisible by 2. Seemingly for any value that isn't 1- ouput scale=2 is also not accepted. I am very new to wayland- how would I track down the source of this error?
<aelius> Seems like it's not inherent to creek itself
<aelius> The exact error being -- wl_surface#22: error 2: Buffer size (210x21) is not divisible by scale (2)
<leon-p> aelius: that's a programming error in creek. sounds like scale isn't handled correctly
<leon-p> to fix this, you'll have to look into where it calculates the dimensions for the buffer based on scale and fix that
<aelius> ok
<aelius> Well, don't hold your breath- I have zero zig experience and I should probably start with "hello world" rather than trying to fix a wayland thing (also near zero experience), heh
<leon-p> fair
<leon-p> there are plenty other bars though, if you prefer less work
schneid3306 has joined #river