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
<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 :)