yiyu has quit [Read error: Connection reset by peer]
yiyu has joined #river
yiyu has quit [Read error: Connection reset by peer]
yiyu has joined #river
leopoldek has quit [Remote host closed the connection]
yiyu has quit [Read error: Connection reset by peer]
yiyu has joined #river
adv8tor has quit [Ping timeout: 264 seconds]
adv8tor has joined #river
yiyu has quit [Ping timeout: 252 seconds]
yiyu has joined #river
yiyu has quit [Read error: Connection reset by peer]
yiyu has joined #river
yiyu has quit [Ping timeout: 248 seconds]
TheAnachron has joined #river
yiyu has joined #river
<TheAnachron>
good morning
catman has quit [Quit: WeeChat 4.4.2]
catman has joined #river
alexherbo2 has joined #river
adv8tor has quit [Ping timeout: 260 seconds]
fitrh has joined #river
talismanick has quit [Ping timeout: 248 seconds]
fitrh has quit [Remote host closed the connection]
<leon-p>
sewn: you mean in your buffer pool? you hard-code two buffers. however realistically situations can arise where that is too little which will cause your bar to crash
<leon-p>
I recommend using a dynamic amount of buffers in your buffer implementation
<leon-p>
you can cull old unused buffers whenever you get a new / recycled one so it won't get out of hand
<leon-p>
as for why someone would send overly long status text: by accident. imagine someone has a status that display the currently playing song and then suddenly one with a long title plays
<leon-p>
for shm on wlroots you could get away with even a single buffer for quite a while, but recently I have seen some of my things need up to three or four sometimes
<sewn>
leon-p: or i can just warn if no buffer is available, similar to how mako or other great wayland projects do. as for the status text, yeah that is fair
<leon-p>
if you just warn and skip drawing, your bar will be in a potentially invalid state until next refresh. Not necessarily nice
leopoldek has joined #river
<leon-p>
however I do suspect the crash I experienced with your bar was caused by it rendering multiple times on startup, apparently faster than the old buffers were released
<leon-p>
so you could also either figure out why you render so often on startup, or driver rendering via surface callbacks
<sewn>
that can only be explained by lots of stdin updates
<leon-p>
there were none :)
<leon-p>
just guessing anyway, if you like I can try to track it down, I have a few minutes
<sewn>
well in that case its just not possible for dam to request that many renders if it setup, recieved configure and just waits for input
<sewn>
probably the wrong channel to discuss it here though, am not sure
<leon-p>
I'll have a look and report back what I find. These are all problems I had to hunt down in some of my widgets as well
yiyu has quit [Ping timeout: 276 seconds]
<leon-p>
ok, it renders four times on start up, on the fourth render no buffer is available and it dies
<leon-p>
sewn: in your layer surface configure handler you should check if the dimensions actually change before you render, that would fix this
<leon-p>
on my system it gets three configures all resulting in the same dimensions, each causes an unecessary redraw
<sewn>
i dont???27;2;13~
<sewn>
oh god
<sewn>
awful mistake lol sorry
<leon-p>
maybe something changed between your river version and mine, no idea
<sewn>
i assumed the compositor just sends one configure event - why would it send another if its just the same data anyway
<vyivel>
in general the compositor should be smart about this yes
<leon-p>
they usually aren't IME
<ifreund>
iirc the scene layer surface helper makes it impossible to dedup the configures
yiyu has joined #river
<leon-p>
I just tried and I even get three identical configures on tag change, oof
<sewn>
i only get one configure per output thats weird
<leon-p>
what river version are you on?
<sewn>
0.3.5
<meidam>
Do any of you use flameshot? I haven't figured out how to make it work with a wlroots compositor. I had the same problem with hyprland
<meidam>
It complains about some environment variable, but I'm pretty sure I set it and it still didn't help
<meidam>
I can give more details later. I'm not at the computer, that has river on it
yiyu has quit [Ping timeout: 248 seconds]
leopoldek has quit [Remote host closed the connection]
yiyu has joined #river
revsuine has joined #river
<revsuine>
Hey riverheads is there a way I can spawn a window and set its output and tags as a one-off? As in, I don't want to make a rule to always spawn that window with those tags and on that output, but I want to once
<Nickli>
isnt that a regular spawn?
<meidam>
revsuine, so you want to spawn a view on a tag and output that you aren't currently focusing on?
yiyu has quit [Ping timeout: 248 seconds]
TheAnachron has quit [Quit: TheAnachron]
<leon-p>
Hmm, one feature I would realy love on codeberg is some placeholder text for the text-entry field for commenting on issues. I'd put some blurb there about not posting "I want this feature too" comments
<The_Buhs>
I'd like that feature too ;)
lordmzte4 has joined #river
lordmzte has quit [Ping timeout: 252 seconds]
lordmzte4 is now known as lordmzte
yiyu has joined #river
<__toor__>
hmm, I got this issue when I enabled dbus with firefox
<__toor__>
(org.mozilla.firefox:2): Gdk-WARNING **: 16:16:00.689: Server is missing xdg_foreign support
<__toor__>
hmm, It seems its not related to dbus, (i turned off dbus session sharing and the same issue)
<leon-p>
xdg-foreign is a protocol which allows clients to lend a surface to another client. IIRC you do need some other IPC as well (like DBUS) so the clients can set everything up. River does not support xdg-foreign. Likely firefox only tries using it when it has DBus
<leon-p>
FWIW I would like xdg-foreign so we can have things like dockapps again
alexherbo2 has quit [Remote host closed the connection]
<__toor__>
hmm, right now I cannot get the select file dialogue open up i firefox, if I have dbus running and exposed
<__toor__>
I don't get it though, firefox should just be able to open up a dialogue without defering it to the dbus system
<leon-p>
portals offers a way to have a separate file dialog, perhaps you have the necessary portals service installed and running, so firefox tries using it, but it's missconfigured and as such you see no file dialog
<__toor__>
is the idea that firefox shouldnt conern itself with system file selection dialgoue and something else should provide those services?
<leon-p>
it's more about sandboxing
<leon-p>
but also integration. i.e. a KDE user would like to see a KDE file dialog
<__toor__>
whats the "server" here? is it river or is it dbus?
<leon-p>
river is a wayland server and does not concern itself with DBus or portals
<leon-p>
DBus is a proxy server, it relays messages between clients
<leon-p>
there are multiple portals services which I guess you could call server even if that's not strictly true
<leon-p>
one main one and dedicated ones providing different features
<leon-p>
i.e. a typical setup would have the wlr portals service for screensharing but also the gtk portals service for file dialogs
<__toor__>
ok, I havnt gotten around to work with that yet
<__toor__>
i know for sure that the screen sharing stuff doesnt work yet
<__toor__>
thanks for taking your time to explain it
leopoldek has joined #river
yiyu has quit [Ping timeout: 260 seconds]
<revsuine>
@Nickli a regular spawn spawns the window on the focused tag and output
<leon-p>
revsuine: there is no clean way to do that unfortunately
<leon-p>
the major problem here is that there is no good way to know which window comes from the spawn command
<leon-p>
there is a way around that with xdg-activation tokens (I think there is a WIP MR from me somewhere) but it's still messy
Nickli has quit [Read error: Connection reset by peer]
Nickli has joined #river
emil2 has joined #river
<emil2>
For some reason setting accel-profile with riverctl doesn't work until I unplug and reconnect my mouse, does anyone have any idea why this might be?
<emil2>
It's a wireless mouse with a USB dongle for what that might be worth.
<ifreund>
emil2: no idea, it seems to work instantly for me
<ifreund>
what river version are you using?
<ifreund>
could perhaps be a libinput bug as well
<emil2>
I'm on river 0.3.5.
<ifreund>
practically the same as mine then
<ifreund>
(master is barely different than 0.3.5 currently and not in any of the relevant places unless I'm mistaken)
<ifreund>
Acutally, I should probably just tag 0.3.6
<ifreund>
there have been a few bugfixes and minor improvements that should get released and it's been a while
<emil2>
Is there a good way to try to isolate if it's a libinput bug?
<emil2>
I should probably try another compositor, but who knows what they do on top of it.
revsuine has quit [Quit: nyaa~]
<ifreund>
emil2: hmm, if it works with a different mouse but not with your wireless one it would almost certainly be a bug lower in the input stack than river
<ifreund>
ah, you could confirm that the output of `libinput list-devices` shows the updated accel profile after running the riverctl command
<ifreund>
actually, this is strange, for me the output of `libinput list-devices` doesn't not change but the behavior of my mouse's movement does
<ifreund>
oh nevermind, that command only lists the defaults not the active configuration. ignore that idea
<emil2>
I'll try to dig up another mouse and see if that behaves differently.
<emil2>
Oh, also, if I restart river that also lets me change the accel-profile.
<emil2>
BRB to connect from another PC so I can restart this one for testing.
emil2 has quit [Quit: WeeChat 4.4.2]
emil1 has joined #river
<emil1>
Okay I figured it out.
<emil1>
I'm running xremap which creates a new input device with a different name, which is the one I should have changed.
<emil1>
I just naively assumed looping over all pointers in my init file would solve it, but xremap takes a few seconds to grab the device so it creates the new one after I've run riverctl.
<ifreund>
emil1: you could use a glob instead, `riverctl input 'pointer-*' accel-profile adaptive`
<emil1>
That works great, thank you!
alexherbo2 has joined #river
alexherbo2 has quit [Remote host closed the connection]