waleee-cl has quit [Quit: Connection closed for inactivity]
travankor has joined #river
trav49458 has joined #river
travankor has quit [Ping timeout: 268 seconds]
trav49458 is now known as travankor
_whitelogger has joined #river
<ifreund>
leon-p: and you're using wlroots 0.12.0?
<leon-p>
definitely
<leon-p>
err... unless packages can override manual installations somehow. I have some older wlroots version installed via pacman, and 0.12.0 build and installed manually
<leon-p>
let me try to remove the package
<ifreund>
I just build wlroots myself and install it to ~/.local
<ifreund>
and set LD_LIBRARY_PATH and whatnot
<leon-p>
dammit, that's it.
<leon-p>
my library path must be bad,
<leon-p>
because I'd expect manually installed stuff to be included first
<leon-p>
thanks for the help anyway
<ifreund>
no problem!
<ifreund>
I thought I saw stuff about the new rendererv6 swapchain in your logs earlier :P
<ifreund>
I think you did uncover a wlroots bug here with the xdg-output teardown
<leon-p>
Interesting, I might try finding it again.
<ifreund>
I'm about to send a patch
<ifreund>
I've fixed the same bug before for other wlroots interfaces :D
<ifreund>
hrm, I've thought of a way we could potentially rework river-options to make it not inherently a memory leak
<ifreund>
we namespace all options to the client that declares them and clean them up when the client exits
<ifreund>
the compositor is also free to create its own namespace
<ifreund>
not sure if this is acutally a good idea yet, will need more though
<ifreund>
would likely influence how we handle layout namespaces as well if we decide that kind of arcitecture would be worth it
<leon-p>
Well, I view river-options also partly as some sort os simple inter-client-communication thingy
<leon-p>
IMO options being always global, never bound to a client is the way to go
<leon-p>
And since rivr sessions are effectively finite, I believe we can live with the "leak"
<leon-p>
(unless of course some malicious client abuses it, but that is a problem for a lot of other protos as well)
<ifreund>
Oh yeah I have no intention to defend against malicious clients
<ifreund>
The "leak" just makes me feel a little icky that's all
waleee-cl has joined #river
<leon-p>
Yeah I get it
<leon-p>
But I don't think binding an options lifetime to a clients connection ia a good idea. river-option is useful mostly because it can be used /between/ clients
<leon-p>
otherwise our init depends on the order of launched things. People probablly will natually call `riverctl set-option whatever` /before/ launching the layout / thing affected by it, which would not work.
<leon-p>
maybe we can have an initial timer: If something has not been accessed by a client other than the declarer, it gets garbage-collected
<leon-p>
with a timeout of a few minutes
<ifreund>
those are some good points yeah
<ifreund>
I'm fine with the current protocol for now
ifreund has quit [Ping timeout: 256 seconds]
ifreund has joined #river
leon-p has quit [Ping timeout: 256 seconds]
leon-p has joined #river
<leon-p>
Option must support some sort of (server internal) callback, otherwise we can not do stuff in response to changes, like re-arranging an output if the user changed the layout namepsace
<leon-p>
it may also solve the issue of linking Options and Layouts, although then we may need a list of callbacks, which is not ideal...
<ifreund>
leon-p: yeah, that's just adding a wl.Signal() to our Option struct
<leon-p>
oh... neat
<ifreund>
yeah, libwayland's signals are literally made for things like this :D
travankor has joined #river
jjanzic has quit [Read error: Connection reset by peer]