ifreund changed the topic of #river to: river - a dynamic tiling wayland compositor || https://github.com/riverwm/river || channel logs: https://libera.irclog.whitequark.org/river/
aryak has joined #river
eShaev9z_ has joined #river
eShaev9z has quit [Ping timeout: 240 seconds]
angry_vincent has joined #river
zxtx has quit [Ping timeout: 248 seconds]
zxtx has joined #river
TheAnachron has joined #river
aryak has quit [Ping timeout: 264 seconds]
leopoldek has quit [Ping timeout: 258 seconds]
notzmv has quit [Ping timeout: 240 seconds]
awesomerly_ has joined #river
awesomerly has quit [Ping timeout: 240 seconds]
awesomerly_ is now known as awesomerly
notzmv has joined #river
IchikaZou has joined #river
IchikaZou has quit [Remote host closed the connection]
IchikaZou has joined #river
IchikaZou has quit [Remote host closed the connection]
IchikaZou has joined #river
IchikaZou has quit [Remote host closed the connection]
IchikaZou has joined #river
kotto has joined #river
IchikaZou has quit [Remote host closed the connection]
talismanick has quit [Ping timeout: 264 seconds]
<isti115> @ifreund: Thanks for the information, hope you're having a good time! :)
cyph3r has joined #river
cyph3r has quit [Remote host closed the connection]
<NickH> Hi all, I'm running the head of river, Ie 7f30c655c, and just tried webrtc screen sharing in firefox and found it is not working.
<NickH> The last time I tried it worked without issues, but that was many months ago, and quite a few things have changed on my system.
<NickH> Would be nice if I could rule out river as the cause. Anyone running the head of river and have this working?
<NickH> Hmmm, maybe I should see if it works with sway...
<NickH> Interesting. Not sure what the problem was but it worked after rebooting into a new kernel.
<dagle> NickH: Did you do an update and then not reboot? Because you could have been in a state where you used different versions of the same libs and they got mad because they wouldn't agree?
<NickH> Old binaries for running processes should remain in ram... hmm, but if firefox was restarted.
<NickH> I'm not actually that fussed to try to understand the cause, just happy to have it working again.
<dagle> Yes things in ram works but things get lazy loaded etc.
<NickH> Hmm... dlopen()
TheAnachron has quit [Quit: TheAnachron]
Guest35 has joined #river
Guest35 has quit [Client Quit]
kerokero has joined #river
<kerokero> Hi, I was wondering if any of the riverwm users use Emacs and Elisp to recreate the EXWM experience. If you do, how is it working for you and what are the advantages and drawbacks?
kotto has quit [Quit: WeeChat 4.0.4]
kerokero has quit [Quit: Client closed]
<leon-p> kerokero has left, but I guess you could create a layout generator that also interfaces with emacs. won't recreate EXWM though
<leon-p> wasn't there a talk recently on some conference about a wayland server specificially written to interface with emacs?
<leon-p> I swear I saw such a thing...
leopoldek has joined #river
<angry_vincent> there is native wayland interface for emacs through pgtk. but i also saw somewhere emac being mentioned as wayland server
<angry_vincent> using gtk with wayland ( is what firefox using too ) is perhaps wrong route
<leon-p> angry_vincent: the pgtk thing is just what emacs uses to draw its window (and yes, a custom wayland backend would have been nicer IMO), kerokero was talking about emacs being in control of window management
<leon-p> huh, the zig-wayland example in the readme is wrong: it uses addProtocolPath() which has been replaced by addCustomProtocol()
tiosgz has joined #river
<tiosgz> i've been thinking about less riverctl calls in the init too much recently, so i tried a variant of riverctl that would accept multiple commands
<tiosgz> the number of riverctl calls reduced from 138 to 38 i believe, but the runtime went from 350ms to 150ms (not including daemons and that stuff)
<tiosgz> not sure if it's worth it, tbh. leaving this here in case someone wanted to know some (not very well-verified) numbers
<tiosgz> it's fast enough with vanilla riverctl and slow enough with this variant
<tiosgz> put it on codeberg if someone wants to check it out themselves though: https://codeberg.org/tiosgz/riverctlseq
<leon-p> connecting just once to river instead of multiple times will absolutely save you a bunch of cycles. the registry is send every time.
<tiosgz> it does save some cycles, but my motivation was the runtime specifically
<tiosgz> which did drop, but not enough for me to call it success
<leon-p> is runtime on start really that bad for you?
<tiosgz> i see a blue frame (before the background changes to brown), so kind of disturbing at most
<leon-p> I think the proper fix would be some feature that made river not render anything until the init has finished. other compositors do the same: read the config first, then start
<leon-p> shell startup time is an issue: you could try loading a compiled binary instead of a shell script as an init
<tiosgz> the issue with this is you could end up locked out if you forgot to unlock it (yeah, using lock-unlock terminology from herbstluftwm)
<leon-p> not familiar with that terminology...
<tiosgz> i do remember trying that out, but ended up with a mess cos i over-engineered it. this was supposed to be a simple and effort-efficient fix
<tiosgz> hlwm also has an init file, which by default calls herbstclient lock at the beginning and herbstclient unlock at the end
<leon-p> ah I see
<tiosgz> which is similar in that it prevents changes in the config from taking place immediately
<leon-p> it could have a timeout
<tiosgz> true
<leon-p> however for this to be effective river would have to "lock" by default, otherwise you are still relying on a call in your init
<tiosgz> with a timeout it wouldn't be a problem
<tiosgz> i believe it's like that in hlwm specifically cos 1) it's voluntary 2) hlwm is also just a client 3) the init file is actually expected to be run multiple times while experimenting (this may be the main reason)
<tiosgz> or just cos it started like that and no-one changed it
<leon-p> If your problem is the default blue background flashing on start, locking from within in the init file does not necessarily solve it. River would need to not render anything until the init is done
<tiosgz> hmm. i think i'll give this a try eventually when i have too many free brain-cycles
<tiosgz> got that :)
maralorn has joined #river
tiosgz has quit [Quit: tiosgz]
<maralorn> Hey there. I have been trying to understand the river layout protocol. Question: Is it allowed to draw two windows at the same position. Is it deterministic which one will be at the top?
<leon-p> maralorn: there are no restrictions w.r.t. positions of windows
<leon-p> stacking order depends on focus order
<maralorn> Great, thanks!
<leon-p> once you have written a layout generator, you can put a link to it into the wiki :)
<leon-p> a bit old, but should still hold up
<maralorn> Yeah, I had just read it. Very helpful. Just didn’t get anything about stacking windows in there.
<maralorn> Now I wonder how hard it would be to write a wayland client.
<leon-p> simple, just a lot of boilerplate
<maralorn> I would very much like to write my own layouting logic. I just don’t care about writing the boilerplate.^^
<leon-p> we have an example layout generator written in C in the repo
<leon-p> so you can rip out the layout from there and replace it with your own
<leon-p> it's in contrib/
<leon-p> there is also a python one, but setting up pythons wayland module is pain
<maralorn> Maybe I try luatile?
<leon-p> no idea if that is still up to date, but can't hurt to try 🤷
<maralorn> Last update in nixos 6months ago.
waleee has joined #river
maralorn has quit [Quit: Client closed]
maralorn has joined #river
<dagle> maralorn: if you don't mind glib, https://github.com/dagle/griver/blob/main/examples/example.lua this has all the boilerplate stuff removed. You could write it in js or python too.
maxxv has joined #river
<maxxv> There weren't any changes in the layout protocol lately, so luatile is as up to date as it ever was :)
<maxxv> There is also https://github.com/MaxVerevkin/river-layout-toolkit (luatile is build on top if it) which is like luatile but for rust. This is more of a library, so I didn't add it to the wiki.
maralorn has quit [Quit: Client closed]
maxxv has quit [Ping timeout: 245 seconds]
waleee has quit [Ping timeout: 260 seconds]
waleee has joined #river
waleee has quit [Ping timeout: 264 seconds]
waleee has joined #river
angry_vincent has quit [Remote host closed the connection]
tmpm697 has joined #river
tmpm697 has quit [Quit: Client closed]
leopoldek has quit [Ping timeout: 258 seconds]
waleee has quit [Ping timeout: 246 seconds]
waleee has joined #river
waleee has quit [Ping timeout: 258 seconds]
groknull has joined #river
groknull has quit [Remote host closed the connection]
waleee has joined #river
leopoldek has joined #river