02:38 <talismanick> As river supports nested sessions, I presume it's possible to sandbox a session around a single app?

08:50 <ifreund> talismanick: I'm not sure quite what you mean by sandbox there

08:50 <ifreund> you can certainly run only

08:51 <ifreund> you can certainly run only a single program in a nested session, but I don't really see the point of that

14:28 <pmnw> Hey. Is there some built-in way to indicate which of the defined modes is active?

14:30 <ifreund> pmnw: no, there isn't currently

14:30 <ifreund> it would probably make sense to have one though

14:31 <nor[m]> This is not exactly built-in but more of a hack: you technically could change the focused windows border color when changing modes :D

14:32 <ifreund> hah, I feel like nor[m] uses river in a way nobody else does :D

14:33 <pmnw> ifreund: Thanks for the info. nor[m]: "a hack" is an understatement :D

14:34 <ifreund> you could also write the mode name to a file in /tmp at the same time as changing modes...

14:36 <nor[m]> ifreund: That happens with any window manager :D None is exactly right for me. But being completely foreign to coding and somewhat new (2 years) to Linux creating my own is not feasible. So I just go with what features are most important to me (currently wayland + tags = river) and just hack the configuration file in very unconventional ways xD

14:42 <pmnw> River's ability to bind a mode to None <key> is a powerful selling point to me. I can then remap Caps_Lock to Menu and have None Menu open a mode of modes of modes, and scripts behind them, so basically everything becomes a keychord. Sway always requires a modifier, but it has a red field in the status bar area that can indicate the enabled mode or even list key options. Very nice. I have to think of a way that could look in River,

14:42 <pmnw> including in a setup without the bar...

14:44 <pmnw> I even like to have a layout mode where all layout-related bindings are striped of their primary modifier (Super) so that I can just hjkl to move around without holding down Super, and then just reverse to the default mode after I'm done. That helps explain why a mode indicator would be nice.

14:45 <ifreund> Yeah I definitely see a use-case for a mode indicator

14:46 <tiosgz> this is a great use case for nor's approach of changing border colors imo

14:46 <tiosgz> a "label somewhere on the bar" would be quite hard to see, though you could recolour the bar too

14:47 <ifreund> It would be pretty straightforward to add an event to the river-status protocol for the current mode

14:47 <ifreund> I'm not very interested in implementing anything client side for that right now though

14:47 <ifreund> If someone wants to do a waybar implementation or similar I'd be happy to do the server side

14:48 <tiosgz> also reminds me of https://github.com/dacyberduck/kiwmi-config/blob/master/preview.gif lol

14:49 <tiosgz> ifreund: i can try my hand at it

14:50 <tiosgz> though i'd like some suggestions as for how everyone would imagine it to behave

14:50 <pmnw> I was thinking of something like a small coloured box with a short identifier in the corner; [Layout mode] [Utilities mode] [Media mode]... Enabled for a list of modes or even everything except Normal/Locked. Speaking of hacks, first one I thought of was notify-sending the mode name to mako or fnott, but that's such a troll idea.

14:53 <tiosgz> ah wait. i guess there's a precedent with all waybar's formats & css classes

14:55 <ifreund> tiosgz: yeah, the UI aspect of it is what I wasn't really interested in dealing with xD

14:55 <ifreund> though waybar is so uber modular that you wouldn't need to make many decisions I don't think

14:55 <ifreund> the protocol change would probably just be this https://0x0.st/oBtX.diff

14:56 <tiosgz> just smash there a "format":"{mode}", innit? :P

14:57 <tiosgz> can you also add a river patch in the next days so i can then test against it?

15:01 <ifreund> tiosgz: shouldn't take me very long :)

15:06 <adelaide> Does anyone else's mako crash the entire system when the notification is too big?

15:09 <ifreund> adelaide: You're probably hitting a bug that's been fixed on river's master branch for a while :/

15:09 <adelaide> I see

15:10 <adelaide> I googled the issue last week but didn't seem to find any conversation about it

15:10 <ifreund> I'll be releasing river 0.2.0 as soon as wlroots 0.16.0 is out, which shouldn't be much more than a month now

15:11 <adelaide> For now I'll just install the master branch then

15:14 <tiosgz> ifreund: btw did you raise the correct interface's version?

15:16 <ifreund> tiosgz: yes, but I forgot to also raise the version of zriver_seat_status_v1 to 3

15:17 <tiosgz> guess i still don't fully understand some aspects of the protocols

15:18 <ifreund> clients only get to choose the version of globals they bind

15:19 <ifreund> for objects created using those globals, the version the client bound the global at is used

15:19 <ifreund> https://wayland.freedesktop.org/docs/html/ch04.html#sect-Protocol-Versioning

15:20 <tiosgz> was on my search for that doc. thanks

15:22 <ifreund> no problem!

15:24 <pmnw> Is there a way to bind a sequence of two or more riverctl commands to a key? Something like: <riverctl map programs None E spawn 'emacsclient -c -- 1>/dev/null && enter-mode normal'> so that mode gets reversed to normal after a command?

15:25 <tiosgz> you can `map -release`

15:26 <ifreund> or alternatively span a shell script that runs any arbitrary riverctl commands

15:26 <ifreund> s/span/spawn/

15:29 <pmnw> Alright, thanks. Both options will do.

15:36 <nor[m]> I just noticed the -release way has this benefit:

15:36 <nor[m]> You can loop over all "final modes" (the modes that don't lead to yet another mode, but only the normal mode after triggering an action).

15:36 <nor[m]> Then within that, loop over all relevant keys (possibly a - z). Combine -release with the mode you are in and the key and tell riverctl to enter normal mode.

15:36 <nor[m]> If you have a bunch of launch keychords and trigger-some-action-keychords and you do this right, this can kill a bunch of birds with one stone.

15:37 <pmnw> Indeed could make for an interesting customisation.

16:24 <ifreund> tiosgz: https://github.com/riverwm/river/pull/614

16:26 <tiosgz> oh, damn. i'm still trying to understand waybar's codebase :D

16:26 <tiosgz> thanks!

16:30 <nor[m]> ifreund: You mentioned 0.2.0. Is there already something to read on what will be new somewhere?

16:30 <ifreund> nor[m]: not really aside from the commit log

16:31 <ifreund> I guess I listed some notable features at the end of my last blog post: https://isaacfreund.com/blog/2022-05/

19:40 <anniehallmoon> ifreund: still using void Linux ?

19:53 <mizzunet> How can I map a key to run ` pkexec bash -c 'kexec -l /boot/vmlinuz-linux-xanmod-edge --initrd=/boot/booster-linux-xanmod-edge.img --reuse-cmdline && kexec -e'`

19:53 <mizzunet> riverctl Control+Alt Delete spawn "pkexec bash -c 'kexec -l /boot/vmlinuz-linux-xanmod-edge --initrd=/boot/booster-linux-xanmod-edge.img --reuse-cmd

19:53 <mizzunet> line && kexec -e'"

19:53 <mizzunet> didn't work

20:22 <ifreund> anniehallmoon: yep

20:22 <ifreund> mizzunet: if the quoting is giving you trouble you can always put it in a script and run that

20:30 <tiosgz> for those interested, a river/mode waybar module is done: https://github.com/tiosgz/Waybar/tree/river-mode

20:31 <tiosgz> still need to recheck the code and copy-paste the manpage before submitting a PR

20:31 <tiosgz> pmnw: ^

20:37 <ifreund> tiosgz: neat, I'll test it and then merge the river PR tomorrow

23:41 <NickH> Nice. This also lead me to discover that Waybar now has a river/window module. Happy days!