<aktina>
novakane: i am using rivercarro, i noticed that i am unable to have my floating window in monacle view, is this the intended behaviour
<aktina>
*monocle
<novakane>
aktina: yes, layout generators don't work on floating windows, that's how river works
grinja2 has quit [Ping timeout: 240 seconds]
grinja2 has joined #river
<TheAnachron>
why would you do that anyway? if you only have one Window and want it monocle, just have it tiled
<TheAnachron>
guess I should try out rivercarro as well, I have it in my bookmarks and on my ToDo for weeks now without testing it yet.
<leon-p>
floating views are a mistake
<leon-p>
subscribe for more hot-takes
<TheAnachron>
I modified river so that I cant have floating windows ;)
leopoldek has quit [Ping timeout: 260 seconds]
<ifreund>
leon-p: I think I want random IDs, it seems much less likely for them to encourage poor client behavior such as ascribing semantic meaning to the ordering of IDs
<ifreund>
it also avoids the need to care about that "generation value" thing the protocol mentions if we have enough entropy
<ifreund>
as for focus-view-by-id, doesn't that have the same open question we've hit before as to what happens if the view it on a different output?
<ifreund>
I think I'm ready to make the call and say that output focus should be changed to the target view's output.
<ifreund>
Should tag focus be set to the target view's tags or should they be added with a bitwise or though?
<novakane>
I think setting the focus to the views tags would be the best choice, although I'm not sure how nice it would be if the view has multiple tags
<novakane>
but the best choice probably depends on people, I'm sure everyone have a different opinion on this
<ifreund>
yeah, which is why we didn't implement it for wlr-foreign-toplevel-management yet
<dnkl>
I'm debugging an issue with fnott (the notification daemon). If I trigger lots of notifications, we'll eventually run outside the screen.
<dnkl>
The way this appears to work is that river allows the layer surface to be created
<dnkl>
but then simply doesn't display it
<dnkl>
so far so good
<dnkl>
but when I start dismissing notifications, notifications lower in the stack is supposed to move up
<dnkl>
but the notification that was initially outside the screen is never displayed
<dnkl>
fnott will update the surface's margins (which should move it into the visible area of the screen), but river never renders the surface
<ifreund>
hmm, how does river respond to the inital commit of layer surface that is outside the screen?
<dnkl>
this means fnott never receives a frame callback for it, and that means fnott will never commit a new buffer for it
<dnkl>
all looks good
<dnkl>
the initial configure looks good, everything looks normal
<dnkl>
it's just that the surface is never displayed, even after later updating its margins
<dnkl>
this may be a gray area in the protocol specification... but I don't see what I can do different in fnott, save maybe force a new buffer commit after updating the margins?
<ifreund>
are you saying that fnott doesn't commit after changing the margins?
<ifreund>
that state is double-buffered and only applied on surface commit as it says in the protocol
<dnkl>
oh.. dang. yes, if there's already a buffer pending, fnott won't commit. Even after updating the margins
<dnkl>
my bad :)
ayushnix has joined #river
<ifreund>
no worries!
ayushnix has joined #river
ayushnix has quit [Changing host]
<dnkl>
I knew that, but missed the missing commit when reading the logs
<dnkl>
thanks!
<dnkl>
ifreund: that worked, thanks again!
<ifreund>
no problem!
<TheAnachron>
ifreund novakane btw huge thank you(s) for your hard work. I like my setup, it's fast, flexible and looks great.
<ifreund>
thanks for the kind words :)
<TheAnachron>
in fact if it wasn't for river and zelbar I wouldn't even have switched from Xorg to Wayland, because all other WMs I've tried are either broken, unmaintained or not allowing me to use my workflow
<TheAnachron>
I think it's good to let people know that their software does actually make a change and not only talk about issues or feature requests. There is so much hard work into all the software and I do really appreciate it.
<dnkl>
+1
<novakane>
TheAnachron: thank you, that's nice of you
<TheAnachron>
novakane btw, with that changed statusbar script (no more delayed stdout) I never again had a single flicker
<novakane>
TheAnachron: glad to hear that :)
<leon-p>
ifreund: since this are our own commands, we can both have and eat the functionality cake. while with the activation request for wlr-foreign-toplevel management we would need to decide, we could just add both river commands
<leon-p>
FWIW hikari has a remotely similar concept: a workspace can "borrow" another workspaces window
jao has joined #river
<TheAnachron>
I've used/tried hikari before going to river and this can both be neat and an annoyance
aryak_ has quit [Remote host closed the connection]
TheAnachron has quit [Quit: TheAnachron]
aryak_ has joined #river
taupiqueur has joined #river
waleee has joined #river
taupiqueur has quit [Ping timeout: 240 seconds]
leopoldek has joined #river
ayushnix has quit [Remote host closed the connection]
ayushnix has joined #river
ayushnix has quit [Changing host]
ayushnix has joined #river
ayushnix has quit [Ping timeout: 245 seconds]
waleee has quit [Ping timeout: 240 seconds]
taupiqueur has joined #river
angry_vincent has quit [Remote host closed the connection]