<bw>
:O awesome, i'll check it out. i want something i can hack on to get it just right
<novakane>
it is in active development so feel free to share your idea or send patches :)
<bw>
will do
waleee has quit [Ping timeout: 258 seconds]
ayushnix has quit [Quit: Client closed]
elshize has quit [Ping timeout: 248 seconds]
elshize has joined #river
snakedye has quit [Ping timeout: 246 seconds]
snakedye has joined #river
<bw>
novakane: any idea where this error is coming from? `fatal: No names found, cannot describe anything.`
<bw>
(when running `zig build`)
<bw>
hmm, it's from `git describe --long`
<bw>
oh i see, it's just noise
<novakane>
bw yeah that's nothing it just because I implemented a version but didn't have tag yet
notzmv has quit [Ping timeout: 240 seconds]
mon_aaraj has quit [Ping timeout: 248 seconds]
mon_aaraj has joined #river
mon_aaraj has quit [Ping timeout: 248 seconds]
<xaltsc>
Hey, how do force fullscreen events (idk how to call that, when you make, say a video on youtube, fullscreen) to stay in their window and not go actually fullscreen ?
<xaltsc>
Many WM on X have a ignore EWMH fullscreen setting for that
<tleydxdy[m]>
just make the compositor ignore it prob
mon_aaraj has joined #river
<xaltsc>
tleydxdy[m]: I don't see anything related to that in the manual
<leon-p>
xaltsc: that is a feature river does not support. It wouldn't be hard to implement, but unfortunately it would go against the xdg-shell protocol and likely break same clients, so I am not sure whether river should implement it.
<tleydxdy[m]>
xdg-shell does say Whether the client is actually put into a fullscreen state is subject to compositor policies.
<tleydxdy[m]>
and most likely it'd only be for specific clients, e.g. the browser
<leon-p>
IIRC the protocol explicitly states that fullscreened clients have the entire output for themselves, so they may rely on that. River doing something different would be a protocol violation, effectively an implementation bug.
<leon-p>
tleydxdy[m]: while river may refuse to honor a fullscreen request, a well written client will then simply accept the refusal and accept that it's not full-screened.
<tleydxdy[m]>
I see
<tleydxdy[m]>
it'll involve some kind of fake output then, messy
<leon-p>
yeah, that'd be a workaround
<leon-p>
it's theoretically possible to have river spawn an additional virtual output, with the Wayland backend as a window in tiself (*inception noise*) where you can then have something fullscreened.
<leon-p>
but that's just a /tiny bit/ too hacky for my taste
<tleydxdy[m]>
river is easy to hack tho
<tleydxdy[m]>
so no biggy for a out of tree patch
<leon-p>
if you want to have local modifications, sure; but upstream features involve a bit more work
notzmv has joined #river
<tleydxdy[m]>
interesting behavior, hmm, seem like monocle is not really doable with the river's layout protocol right now
<tleydxdy[m]>
since monocle needs to shuffle the stack when user switch focus
<leon-p>
it's kinda possible, since river always renders the focused window on top, however you have to live with the rendering-order changing when you focus a floating view or different output
<tleydxdy[m]>
yeah exactly
<tleydxdy[m]>
it's the behavior I'm taking about
<tleydxdy[m]>
actually the difference in how focus works between river and dwm is causing a lot of user error for me
<leon-p>
the problem is that intuitively you'd want the rendering order / stacking order to be influenced by the order in which windows are focused, however most of rivers code is written to allow multi-seat setups, where you'd have more than one focused window. Now it's suddenly not so intuitive anymore.
<tleydxdy[m]>
how many people actually use multi-seat?
<leon-p>
none, since while most river code supports it, seat.len == 1 is still hardcoded :D
<tleydxdy[m]>
what would it look like actually?
<leon-p>
tleydxdy[m]: a seat is basically a collection of input devices bundled with such abstract concepts as pointer focus and keyboard focus. For example, with two seats, you'd have two cursors and two people could work in the same river session side-by-side, focusing different windows and typing on physically different keyboards.
<tleydxdy[m]>
what if the two people focus two window that overlaps?
<leon-p>
a more useful application would be to assign specialied input devices, such as graphical drawing tablets or those weirdo CAD mouses, to their own seat so that they don't interfere with the main input devices.
<tleydxdy[m]>
imo there ought to be a "master" seat that dictates window order etc
<leon-p>
tleydxdy[m]: that's an implementation detail. I'd guess most compositors implementing proper multi-seat will put the window focused last on top
<leon-p>
tleydxdy[m]: disagree, just like there should be no main output. With well-designed behaviour this really isn't necessary.
<tleydxdy[m]>
leon-p: that's just treating the two seats as one wrt window order right?
<leon-p>
yep
<leon-p>
since in most cases multiple seats are likely still operated by the same user, this is the least confusing way to do it
<tleydxdy[m]>
ig I'm still not getting this
<tleydxdy[m]>
> the problem is that intuitively you'd want the rendering order / stacking order to be influenced by the order in which windows are focused, however most of rivers code is written to allow multi-seat setups, where you'd have more than one focused window. Now it's suddenly not so intuitive anymore.
<tleydxdy[m]>
it would just be the case where one window on top the focus stack is focused or the n windows on top the focused stack is focused
<leon-p>
basically the problem is deciding how to integrate multiple seats focus orders. While I say they should be folded together based on global chronological order, other people may have different ideas
<leon-p>
also implementation wise it gets bit more involved, since you still need the individual focus orders, just like the global one.
<tleydxdy[m]>
yeah, sounds like a mess
<leon-p>
not a mess, just some decisions that have to be made
<leon-p>
and the correctness of the implementation would be worth the extra complexity.
<tleydxdy[m]>
which way those decisions go would be influenced by whether it's a single-user multi-seat scenario, or a multi-user multi-seat scenario right?
<tleydxdy[m]>
or even the style of collaboration it is (at least for multi-user)
snakedye has quit [Read error: Connection reset by peer]
snakedye has joined #river
<tleydxdy[m]>
kind of a geometrically increasing problem space, if the goal is general purpose
<leon-p>
a single-seat setup is just a subset of a multi-seat setup, so don't actually have to solve this problem more than once. Solve it for n, and n-1 just as n+1 follow :)
<leon-p>
and since multi-seat with a single user is considerably less fringe than multi-seat multi-user, that's what I'd focus on
<tleydxdy[m]>
leon-p: is it tho? say remote desktop support that it do
<tleydxdy[m]>
IT
<tleydxdy[m]>
e.g. on windows teams can remote desktop with two cursor one for the local user and one for the remote one
<leon-p>
I mean, consider the target audience. Remote desktop is a windows / macos thing. In the civilized world we have SSH, so this is really not a concern.
<tleydxdy[m]>
that is probably very common at this point
<tleydxdy[m]>
sure
<tleydxdy[m]>
you did mention collaboration tho
<leon-p>
we shouldn't solve programs that did not implement proper collaboration support themselves nor use cases that don't make use of such
<leon-p>
it's not rivers job to fix gaps in other programs feature-set
<leon-p>
just like we don't work around client bugs
mon_aaraj has quit [Ping timeout: 258 seconds]
mon_aaraj has joined #river
lxsameer has quit [Ping timeout: 248 seconds]
lxsameer1 has joined #river
mon_aaraj has quit [Ping timeout: 255 seconds]
mon_aaraj has joined #river
elshize has quit [Ping timeout: 244 seconds]
elshize has joined #river
snakedye has quit [Ping timeout: 248 seconds]
lxsameer1 has quit [Ping timeout: 248 seconds]
lxsameer1 has joined #river
talismanick has quit [Remote host closed the connection]
snakedye has joined #river
talismanick has joined #river
lxsameer1 has quit [Ping timeout: 256 seconds]
lxsameer1 has joined #river
talismanick has quit [Read error: Connection reset by peer]
talismanick has joined #river
waleee has joined #river
talismanick has quit [Remote host closed the connection]