<vyivel>
is there some explanation of how tags work in river? i found the riverctl(1) to be somewhat unclear
<vyivel>
specifically, do i understand correctly that tags are per-output? how does this work with floating views? what if a floating view changes its position while invisible? how is a focused output defined?
<palanix>
tags exist per monitor and are just a u32 with each digit being one tag. a client also has a u32 tag. a client may be assigned to multiple tags at once
<palanix>
you can also view multiple tags at once
<vyivel>
to clarify, whether a view is visible is defined as (view-tags | output-tags) != 0, right?
<palanix>
no, it's (view-tags & output-tags) != 0
lordmzte has joined #river
<vyivel>
oh right that's i meant to write lol
<larstiq>
and multiple tags can be visible at once, so then you get any of the windows on those tags
<larstiq>
you still only display each once. I wonder what would go wrong if you showed a window on more than one monitor at a time
alexherbo2 has quit [Remote host closed the connection]
<ifreund>
the main problem with showing a window on more than one output at once is that it would need to have the same (possibly scaled) dimensions everywhere
<ifreund>
which wouldn't make sense for tiling of course
<ifreund>
otherwise there's nothing technical stopping that at the Wayland protocol level afaik
alexherbo2 has joined #river
<larstiq>
ah good point
<larstiq>
how does that work with display mirroring, river only sees a single monitor or does it need to be aware of such things?
Keeto has joined #river
tiosgz has joined #river
<tiosgz>
screen mirroring is an open question. wl-mirror (or what is it) records one screen and shows it in another window
<tiosgz>
vyivel: floating views are subject to tags and output-relative positioning restricted to the output's boundaries if that was your question
<vyivel>
aha
<vyivel>
so it's impossible for a view to be partially visible on one output and partially visible on another?
<tiosgz>
yep, impossible
<vyivel>
i see, thanks
alexherbo2 has quit [Remote host closed the connection]
<ifreund>
the river-window-management-v1 protocol will make this stuff the decision of the window manager rather than the compositor as well
bwbuhse has quit [Ping timeout: 244 seconds]
<vyivel>
are there any river-window-management-v1 clients?
<ifreund>
there is a hacky test one on the rwm branch called rivercompat
<ifreund>
the goal of that branch is to make rivercompat do everything river master currently does
<ifreund>
I'm still breaking the rwm protocol whenever I feel like it so it's a bit early for a lot of clients to exist still
<ifreund>
I made a ton of progress in the last 2 weeks though
<vyivel>
i'm just interested in tag management (especially in multi-monitor setups), currently looking at what different compositors do
<ifreund>
fwiw I'm not entirely happy with how tags work in river currently
<ifreund>
I basically cargo culted the behavior from dwm
<ifreund>
A larger part of why I'm working on the rwm protocol is so I can experiment with alternative window management schemes with a faster iteration time
<ifreund>
I'd like to try getting rid of strict workspaces/tags entirely and have a more dynamic approach for choosing what windows to display
alexherbo2 has joined #river
<ifreund>
a less dramatic change from the river status quo would be to share tags across all outputs and only allow a single tag per window
<vyivel>
that's what i have right now
alexherbo2 has quit [Remote host closed the connection]
alexherbo2 has joined #river
tiosgz has quit [Quit: nyaa~]
alexherbo2 has quit [Remote host closed the connection]
Keeto has quit [Ping timeout: 264 seconds]
AlxFG has quit [Remote host closed the connection]
AlxFG has joined #river
AlxFG has quit [Remote host closed the connection]
AlxFG has joined #river
bwbuhse has joined #river
Guest1031 has joined #river
Guest1031 has quit [Client Quit]
<ifreund>
interactive resize of multiple windows at once including mpv seems to work now
<ifreund>
I think I've learned a thing or two about writing wayland compositors over the past few years, this didn't take anywhere near as much debugging as I thought it would
<ifreund>
I will say that I haven't tried the true hard-mode yet though, that comes when we add window manager decoration surfaces for the windows being resized into the mix
<ifreund>
I think it's now time for me to take rivercompat beyond a minimal test window manager and shoot for feature parity with river 0.3
wereii has joined #river
<ifreund>
or maybe decoration surfaces are the next step, it would be goot to make sure the protocol design for those is solid
<wereii>
hello, I might be just dumb and/or blind, but (roughly) how can I implement "focus next tag" aka set-focused-tag +1 or -1