waleee-cl has quit [Quit: Connection closed for inactivity]
maringuu has quit [Read error: Connection reset by peer]
maringuu has joined #river
leon-p has quit [Quit: leaving]
gspe has joined #river
gspe has quit [Remote host closed the connection]
yyp has joined #river
gspe has joined #river
gspe has left #river [#river]
gspe has joined #river
gspe has quit [Remote host closed the connection]
yyp has quit [Remote host closed the connection]
<novakane[m]>
where does river-layouts.7 man page come from btw?
<novakane[m]>
I mean there is no source file in doc/ so how does it works for this one
<ifreund>
novakane[m]: it used to exist but was removed when we switched to the river-layout protocol
<ifreund>
you probably just haven't run a git clean since then
maringuu has quit [Ping timeout: 250 seconds]
maringuu has joined #river
<novakane[m]>
ifreund: oh ok that's explain why I coudn't find anything with fd or ripgrep
<novakane[m]>
there is still a mention in river man page see also section though
gspe has joined #river
<ifreund>
not any more :P
<novakane[m]>
Ah that's just the river update that I have been waiting for weeks :p
<ifreund>
xD
<novakane[m]>
ifreund with your system of copying svdir to /tmp your services works great when you use river in river or another tty right?
gspe has quit [Remote host closed the connection]
gspe has joined #river
<ifreund>
yep, the point of it is to support multiple parallel river sessions with separate runsvdir instances
<novakane[m]>
nice, I should do this
<novakane[m]>
my current setup works good but not having layout or foot server whent I open an other instance of river or any compositor is annoying
gspe has quit [Remote host closed the connection]
gspe has joined #river
gspe has quit [Remote host closed the connection]
gspe has joined #river
yyp has joined #river
gspe has quit [Remote host closed the connection]
gspe has joined #river
waleee-cl has joined #river
leon-p has joined #river
<ifreund>
finally picked up a second monitor, now I just need another dvi or hdmi cable
<ifreund>
multi-monitor ergonomics in river should be getting a bit more attention soon
<novakane[m]>
is river bad with multi monitor right now?
<ifreund>
I can't really say, I haven't used it aside from WLR_WL_OUTPUTS=N in a nested session for testing
<ifreund>
it's pretty much what dwm does, so functional but kinda awkward
<novakane[m]>
well two monitor you're a true streamer now :P
<leon-p>
the biggest problem IMO is switching between monitors. There is no indication other than the window border. And often the monitor you focus does not have windows yet, so it involves some guessing.
<novakane[m]>
oh yeah doesn't sound ideal I guess
<yyp>
Cursor?
<leon-p>
Too small
<leon-p>
(also does not warp yet, afaik)
<novakane[m]>
no problem on my 13" :P
<leon-p>
The biggest improvement you can make rn for multimonitor is configuring Super-Tab to switch between them. If you only have two monitors, there really is no need for dedicated up and down cycling.
<leon-p>
And the default binds are a bit awkward
<leon-p>
although I can't complain, since I was the one who introduced Super+Alt+Control binds :D
<leon-p>
I wonder if we could maybe flash the output that is focused. Maybe just increase the gamma for 0.2 seconds or something.
<leon-p>
ifreund: is there a reason Output.layoutNamespace uses (self: Self) instead of (self: *Self)? Isn't that an unecessary copy?
<ifreund>
nope, the zig compiler will optimize that to a *const Self currently
<leon-p>
i see
<ifreund>
leon-p: I think it would be neat to extend the current opacity focus animation to handle animation to an arbitrary rgba value, not just fully transparent
<ifreund>
which I think does a good job at show which view is focused
<leon-p>
What would we need to add? We have a target opacity for focused and unfocused, which works for simple animations already.
<ifreund>
I'd want mine to flash the color I use for focused borders over the whole view and quickly fade back to normal
<leon-p>
ah I see.
<leon-p>
That is a bit more involved I guess
<ifreund>
Yeah, I don't plan on trying to implement it anytime soon, just have that in the back of my mind as something to explore in the future
<leon-p>
we do the opacity changing by tweeking a (gamma?) knob in a wlroots render helper
<leon-p>
we could cheat a bit, and render a rectangle in that colour beneath the view and then do the opacity animation. No idea if that looks good though...
<leon-p>
otherwise I don't think that can be done without a shader, which means custom renderer
<leon-p>
not that I am opposed to that, I just think it is a bit early :P
<ifreund>
Yeah that was my thought for the implementation as well using the limited wlr_renderer functions
<leon-p>
btw, just tried the output flashing thing. It certainly works and easiely indicates which output is focused. But am not sure I like it. It's just a bit too ... aggressive
<ifreund>
Yeah, way too early for a custom renderer
<ifreund>
(if ever, I'd take some convincing)
<ifreund>
flashing the whole output sounded a little too agressive to me as well, which is why I thought about flashing only the focused view again
<leon-p>
whether we need a custom rendere depends on how much eye candy we want. As far as I am conerned, all I want is motif-style borders and shadows and I am good.
<leon-p>
what if you have no view on the output though?
<ifreund>
true, wouldn't help then
<leon-p>
maybe instead of flashing the entire output, flash a 20px border around its edges.
<leon-p>
eiter way, I don't think we should make such changes until damage tracking is implemented. It only leads to hacks otherwise
<ifreund>
agreed
<leon-p>
we aneed to change the opacity anymation anyway, since it would be nicer if it updated every frame intead of on pre-defined steps