10:11 <dnkl> there's a new protocol, system-bell, in wayland-protocols 1.38... anyone know if there are any compositors implementing it yet?

10:14 <dnkl> I'm guessing gnome... but hopefully others too?

10:16 <j`ey> https://wayland.app/protocols/xdg-system-bell-v1 "No compositor support found" :S

10:16 <vyivel> wlroots has an impl, if you just want to test it you can trivially add support to tinywl

10:17 <j`ey> how does it differ from the 'urgent' stuff

10:18 <vyivel> semantically

10:18 <dnkl> vyivel: thanks, but even that may be too much for my limited time... 😅. It's not a difficult protocol, so mostly interrested in seeing how different compositors implement it, visually

10:19 <vyivel> i presume a window flash

10:19 <dnkl> j`ey: it's up to the compositor; it could treat it just like urgency. But fwiw, this protocol specifically targets terminal's and BEL, while urgency just means "an application wants something"

10:20 <vyivel> not necessarily terminals i think

10:24 <dnkl> of course not, but the release notes mentions terminals specifically. So pretty sure that (terminals) were the driving force behind the new protocol

10:24 <dnkl> anyway, support for it is now on foot's master branch

10:25 <dnkl> completely untested, as it should be 😂

10:26 <ifreund> dnkl: maybe look at what the gtk_shell system_bell request does in gnome/mutter

10:28 <ifreund> from reading the w-p MR, the behavior of the compositor seems to configurable through accessibility settings

10:29 <dnkl> I _could_ look at gnome, but to be honest, I'm more interrested in what other compositors might do... anyway, it's mostly curiosity; from the client perspective, the protocol is dead simple

10:30 <ifreund> fwiw, I have no concrete plans to implement this for river as I genuinely don't know how users would want it to work

10:30 <bapt> please no bell ;)

10:31 <ifreund> river definitely will never beep at you

11:22 <dnkl> ifreund: if I was writing a compositor I wouldn't know what to do either :)