11:53 <tiosgz> ifreund: do you plan for the wm protocol to support swapping the wm at runtime? if so, what should it do with already open windows?

11:53 <ifreund> tiosgz: yes, I definitely want to support swapping and restarting the wm without restarting river, as well as handling the wm crashing gracefully

11:55 <ifreund> I don't think there is any way to preserve window manager internal state across restarts without the window manager itself serializing that state to disk though

11:55 <ifreund> I intend to add persistent window ids to make that possible

11:55 <ifreund> as for switching wms, I think we can advertise all currently open windows to the new wm as if they were newly opened.

11:56 <tiosgz> i'm asking mainly because right now the protocol says the window is hidden until explicitly shown, which may or may not be expected

11:57 <ifreund> I mean, we can hide all the currently open windows when the new window manager starts...

11:59 <tiosgz> that indicates quite clearly that something is wrong, but also means you can't use an open terminal to fix it (i know there's tty and that's probably the only certainty)

12:00 <ifreund> are you talking about the situation when there is no active wm?

12:00 <tiosgz> anyway, just wanted to point this out in case you hadn't thought about it :)

12:00 <tiosgz> yes, mostly that

12:00 <tiosgz> after the wm crashes and no other wm has started yet

12:01 <ifreund> I'm not quite sure how I want to solve that yet, probably a super basic floating wm

12:01 <ifreund> (built into river)

12:02 <ifreund> kinda like how we handle not having a layout generator running currently, but with even less features cause no tags, keybindings, etc.

12:02 <tiosgz> makes sense

12:03 <ifreund> Anyhow, I definitely care about making switching between wms, developing wms, restarting wms, dealing with crashing wms, etc as smooth as possible

12:06 <ifreund> One approach would be to hardcode a list of terminal emulators and try to start one if there is no wm running

12:11 <ifreund> Here's another idea: we ship a river-fallback wm with river that displays a basic GUI with options to exit river and start arbitrary programs

12:12 <ifreund> maybe an option to restart the previous wm if we make river aware of that binary somehow

12:12 <ifreund> and river should refuse to start if river-fallback doesn't exist

12:15 <tiosgz> oops. i didn't mean to get you into solving this edge case right now 🤦. sorry if it's taken away your attention for the rest of the day

12:16 <tiosgz> though i quite like the restricted fallback idea

12:16 <ifreund> no worries at all! I've been thinking about how best to do this protocol for a long time and can't really stop thinking about it

12:17 <ifreund> It's very nice to finally start putting the ideas into protocol xml and making things more concrete

12:17 <ifreund> yeah, I think the river-fallback idea probably has the best UX

19:45 <leon-p> something in the style of an old amiga guru meditation would be kinda funny

19:46 <leon-p> instead of it being a fallback WM, it could be just a layer-shell program that takes arbitrary text-input and displays a warning overlay

19:46 <leon-p> (like swaymsg)

19:47 <leon-p> would be more flexible, it could also be used for other warnings

19:47 <leon-p> and could then also be used by other programs. f.e. the WM could use it to warn about bad configuration files

19:48 <leon-p> I wonder if river should try to restart the WM if it crashes

20:31 <leon-p> heh, I think I'll probably clone twm or some other ancient X WM for a blogpost

21:22 <Eyezap> Hi! Getting comfy on river, its been really amazing so far. Wanted to get a temperature check on having many keybinds / modes to support shortcuts with multiple keys—is this likely to make things slow or strange? Should be less than 100 modes

21:24 <Eyezap> I want to only use 3 keys to index 9 tags, I think I'll go ahead and try it

21:42 <ifreund> yeah, probably not an issue